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ABSTRACT 


NPS Combat Systems students learn about robots and autonomous weapons 
during group design projects in the SE 3015 course sequence. This sequence is designed 
to provide experience in combat systems development. The capstone project is the Robot 
Wars Competition, where pairs of student- designed autonomous robots battle each other. 
This thesis extends this competition into the arena of simulation and modeling. Our 
motivation is to further students’ understanding of the strengths and weaknesses of 


computer modeling and simulation in combat systems design and testing. 


This thesis creates a simulation foundation of the Robot Wars Competition. The 
simulation has been designed in two main parts, a C++ program that manipulates the 
Simbots on the playing field and generates data files of their movements, and a 3D 
graphical visualization that allows the user to see the Simbots in action. The C++ 
program uses a Simbot class to instantiate two Simbots which are composed of three 
basic components: base, optics and weapons. The graphics portion uses data files created 
in the main simulation and displays in 3D animation. The simulation correctly replicates 
the logical and physical aspects of the robot competition. Future research on the physical 
aspects of the component parts and the graphics package can be integrated with this 


foundation. 
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I. INTRODUCTION 


A. OVERVIEW 

The SE 3015 Robot Wars Competition is a culmination of four quarters of electronics, 
control systems and signal analysis course work for masters students in the Combat Systems 
curriculum. As stated in the NPS course catalog: 

[ In the final quarter of the sequence], this course applies the concepts of the 

Applied Physics I-III sequence to digital data acquisition and control systems. The 

course covers microprocessor architectures and digital communications using 

serial, RS-232, parallel, IEEE-488 interfaces, as well as digital and analog 

interfacing. Two key areas involve the use of small computers for the control of, 

and data acquisition from peripheral devices. The use of electro-mechanical servo 

systems for closed-loop feedback control of mechanical devices, such as 

positioning, pointing and tracking systems. (NPS course catalog, p. 307) 

The SE 3015 robot is designed with both standard and student defined parts. All students 
are provided a base platform, standard gun and beacon. The students are required to build the 
optical circuit and the fire control circuit for the standard gun using supplied parts and circuit 
diagrams. Depending on the particular rules for the course, students can add additional weapons 
or decoys of their own design to the robot. Appendix A contains Robot Wars rules for a recent 
competition. Following these rules, the students are required to program individual robots with 
tactics to search, seek and fire upon the other robot on the playing field. 

This thesis builds the foundation for extending the SE 3015 Robot Wars competition into 
the realm of computer simulation and modelling. The physical SE 3015 robot is modeled in 


software to simulate its physical behavior in response to the external environment and internal 


control structure. The logic of the SE 3015 robot Dynamic C code (Z-World Engineering, 


1995) is preserved as best possible in the simulation environment to accurately recreate the 
tactics and reactions programmed. This thesis provides a simulation foundation which 
incorporates only rudimentary aspects of physics in simulating robot motion, optics and weapons 


systems in order to establish an initial competition simulation version. 


B. PURPOSE 

The purpose of this thesis is to provide robot code implemented in a simulated 
competition environment, thereby providing the ability to compare the performance of the 
simulation to the actual competition. Manipulation of this model can provide insights into the 
strengths and weaknesses of both simulations and robot tactics. The simulation foundation was 
chosen to touch on all aspects of the Robot Wars Competition so as to create a working model 


for use in future development. 


C. THESIS ORGANIZATION 

This thesis consists of overall descriptions of the SE 3015 robot, its control structure, the 
simulation robot (Simbot) and the major components of the robot. This thesis covers the basic 
design of the robot wars computer simulation, the setting up the initial robot class and the 
graphics display environment. Initial models of the base, optics, and weapons have been created 
for use in the simulation. 

Chapter I describes the problem being studied in detail. Chapters II and IV provide a 
general description of SE 3015 robot and its control structure, detailing the parameters to be used 


and the functions mapped to the simulation. Chapter V covers the simulation environment, 


simulation robot and their control structure. The SE 3015 project robot (Figure 1.1) consists of 
three main hardware portions: Chapter VI for the robot base, Chapter VII for the optics, and 
Chapter VIII for the weapons. Chapter IX discusses the targeting and tactics used in the Robot 


Wars Competition. 





Figure 1.1 SE robot side view 





Il. DESCRIPTION OF THE PROBLEM 


The scope of this thesis is to create a "foundation" model of the "Robot Wars" robot that 
can interact with its opponent on a simulated playing field. The foundation is designed to allow 
future student research to concentrate on improved simulation of one specific area while having 
the capability to simulate the competition for testing and analysis. This work also provides a 
visualization of the Robot Wars Competition to observe the interaction of the robots on the 
playing field, thereby permitting analysis and improvement of tactical software. 

In order to simulate the Robot Wars Competition, a computer model of the physical 
robot is created to interact on the playing field with opponents. The robots used in the SE 3015 
Robot ees Competition are built in three parts: the base, the optics and the weapons systems. 
Similar in construction, the bases are supplied to the student. The base controls the robot 
motion and houses it’s computer. The optics allow the robot to see its opponent and the weapons 
system is used to attack the opponent. Optics and weapons are constructed by the student using 
supplied circuit diagrams and parts, but each student can modify them to fit their requirements. 
To constrain the development of the simulation, the differences between robots are limited to the 
optical circuit and the weapons systems. The robot base units are considered identical and 
assumed in perfect working order. 

The SE 3015 robots are programmed in Dynamic C (Z-World Engineering, 1995) and 
function autonomously. They interact with each other only if they detect their opponents 
beacon with the optical sensors or bump into each other on the playing field. They also interact 


with the playing field edges. The simulation is required to preserve the autonomous interaction 


of the robots, and also maintain the logic and control systems flow. The Dynamic C code of the 
robot is integrated into the Simbot’s C++ simulation code. The tactics and logic are preserved to 
replicate the actions and reactions expected of the original SE 3015 robots based on the 
Dynamic C code. 

The Robot Wars simulation foundation developed here incorporates a C++ class structure 
for the robot, a simulation control program to manipulate the robot players on the field, and an 


animation program to provide a 3-dimensional (3D) display of the simulation. 


Il. THE SE 3015 ROBOT 


To create the foundation simulated robot, Simbot, the SE 3015 robot must be defined and 
broken into its major physical components and parameters, its code interpreted and mapped to 
the simulation, and its operations analyzed. The incorporated components are the robot base or 
movement, optics or vision and weapons. For the baseline simulation, many of the non-critical 
components have been omitted and the parameters ignored to simplify the initial simulation. 

This section describes which components and parameters were the incorporated or ignored to 
create the ideal Simbot. The standard gun breakdown is shown as well as the parameters which 


are mapped to the simulation and a typical playing field. 


A. ROBOT COMPONENTS 

The following is a breakdown of the basic SE 3015 robot, including components and 
physical attributes that affect its performance. Although many of these items have been ignored 
they are listed for completeness and as a guide for future work. 

The attributes which are in bold are considered to be the most critical to the simulation. 
These are attributes for which measurements and assumptions have been made which directly 
alter the Simbot’s behavior. An example of such assumptions is to take the conditions of the 
irwile to be ideal, such as a uniform weight distribution for the robot. By assuming the robot 
to be perfectly balanced, the effects of dragging the stoppers along the floor and subsequent 
friction can be ignored. This assumption were made to create the Simbot and show its 
movement as directed by the code. In actuality, an off-centered robot will move slower and not 


properly follow directions from the code. This could also effect the firing angle of the weapon. 


The specific components and attributes italicized in the list have been ignored in the 
simulation. The complexity of the measurements and the lack of robot development 
standardization contribute to the difficulties in simulating some of these items. For example, 
the signal levels obtained from the photo diodes are a function of the nose/eye geometry, circuit 
design, and the batteries used. 

Some attributes do not cause significant variation to the simulation if modeled. For 
example, the energy level of batteries used in the robot can affect the performance if they are not 
stable and within adequate charge levels. The robot motor may function perfectly while the 
battery is fully charged, but fail to function (i.e., move the robot) if the battery voltage level falls 
too low. There is no detected intermediate situation where the robot motor will function but not 
at peak efficiency. This is in contrast - the eye circuit which, when the batteries begin to get 
low, will start sending erroneous reading along with the good readings before complete failure. 
However, if the student keeps the robot main battery charged as instructed and uses fresh 
batteries for all other cases, the robot will perform the same on each use. The effects of the 
batteries only become important after extended usage. In this simulation, none of the 
performance characteristics are considered battery dependent and therefore all batteries have 
been ignored. Similar lines of reasoning have been used in deciding which of the many 
parameters, listed in Tables 3.1 through 3.4, are modeled in the simulation. 

The primary functions of the SE 3015 are movement, targeting and firing. The 
movement (as described in Chapter VI) is a function of the motor and wheels as directed by the 


robot code commands. The targeting determined by the signal level of the opponent beacon as 


physical robot 

a. weight 

b. height 

oh diameter 

d rubber stoppers (balance) 
1. placement 
il. height 

motor - drive train 
angular velocity 
angular acceleration 
friction 
torque of drive shaft 


radius 

width 

placement 

linear velocity 
linear acceleration 
friction 

ower supply (main battery) 
voltage level 
stability 

battery life 
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b. 
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Pp 
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edge detectors 
a. placement on robot 
1s fore edge detector 
il. aft edge detector 
tolerance 
detection method 
1. optical 
il. EMF 
bumpers 
a. placement on robot 
1. fore bumper 
11. aft bumper 
b. obstructions 
computer 
a. baud rate 
b. program type 
1 while loops 
i costatements 





Table 3.1 Robot Body 


photo detectors 

a. height on robot 

b. position on robot 

1. angle 
geometry of detectors 
1. nose length 
il. detector angle 


relative 


to centerline 


circuitry 

a. number of circuits 

b. cross talk/interference 
c. gain 

d. bandwidth 

battery 

a. voltage level 

b. voltage stability 

C. battery life 





Table 3.2 Robot Optics 


circuit board 
beacon body 
a. beacon alignment 


placement on robot 
a. height 

b. obstructions 
batteries 


Table 3.3 Beacon 





standard gun 


a. 


ie 


barrel 
i. length 
il. radius 
ili. friction 
lv. angle 
magazine 
i. length 
il. radius 
lil. friction 
motor 
ib speed 
(1) power supply 
wheel radius 
(1) friction 
(2) o-ring type 


firing solenoid 
(1) duration of signal 
(2) length of pin 
projectile velocity 
i. internal velocity of barrel 
il. exit velocity 
dispersion 


ammunition 


a. 


size 

1. uniform/spherical 
ii. other shapes 
weight 

density 

shape 

drag 





Table 3.4 Robot Weapon 
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detected by the optic circuit which is then evaluated by the robot programmed tactics (as 
described in Chapter LX) to determine the proper reaction or action. The weapons (as described 


in Chapter VIII) are fired based on a targeting solution determined by the robot code. 


B. ROBOT PARAMETERS 

The Simbots have been set with default parameters chosen to simulate typical behavior. 
The specific incorporated parameters, their corresponding variable names in the simulation, and 
default values are listed in Table 3.5. These are the physical parameters that have been 
represented in the simulation. These parameters are modifiable within the class by changing the 
Simbot Class object parameters. 

Some of the variables will have more than one name to prevent confusion when switching 
between the simulation main program and the robot class. Where applicable, measurements are 
given first in English units followed by the simulation units. The scale is approximately 1 foot 
to 100 grid units. Simulation units were used to conform to the graphics package used to 
provide the simulation animation. This scale converts the playing field measurements of 16’ x 
16’to 1600 x 1600 grid units and the robot diameter of 12.75" to 100 grid units. 

The eye widths and nose length are set at aratio of 1:1.5. This ratio makes the limiting 
ama 33°. The limiting angle is critical to left and right discrimination and the robot’s ability to 
determine the relative location of its opponent on the playing field; see Chapter V, Section D for 
further discussion. The wheel radius and separation distance are scaled at 1:4 for convenience of 
assessing the rotation angles and movements. The default angular velocities of the wheels 


arerepresented by a range of velocities -15 to 15 as sent by the motor control string, described in 


I] 


Chapter V, Section B. The true change in velocities is nevertheless non linear from one to the 
next (i.e., speed 4 is not four times faster than speed 1). The nonlinearity of the wheel speed 
changes is evident when the robot cycles through the wheel speeds. Although wheel speed 


changes are not calibrated, they are not a major factor at this point in the simulation 


development. 










simbot Class 
parameter variable name default measurement 


igen 
a a 


Table 3.5 Robot Parameter - simulation variable mapping with default values 















C. WEAPONS MODEL AND PARAMETERS 
The standard gun is the only weapon modeled for the simulation foundation. The 


standard gun and bullets are mapped to matrices that contain both their parameters and 


2 


information concerning their current status. Currently, the simulation includes only the exit 
velocity of the standard gun and the magazine size. The bullets are held in a single magazine 
(matrix) of m x 8, where m is the total number of bullets available. The weapons matrix is n x 4 
where n indicates the number of weapons types available. A breakdown of the bulles matrix is 


contained in Table 3.6, and the weapons matrix appears in Table 3.7. 





row element parameter description default value 


bullet[x][0] status flag 0 - not fired 0 - not fired 
] - active 
2 - Spent 
bullet[x][1] launch angle Simbot gun angle set at time 
of launch 
bullet[x][2] exit velocity of gun launched 
from 
bullet[x][3] X position Simbot x position set at time 
of launch 
bullet[x [4] y position gun[x][3] value set at time of 
launch 
bullet[x][5] Z position Simbot z position set at time 
of launch 
bullet[x][7] gun launched from a 


Table 3.6 Bullet matrix row elements 
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Table 3.7 weapons matrix row elements 


D. PLAYING FIELD 

The SE 3015 Robot Wars competitions is held on a 16’ x 16’ playing field which is ringed 
by a wire to facilitate edge detection as shown in Figure 3.1. The wire used to line the edge emits 
an EMF signal of 22 kHz. The SE 3015 robots are equipped with edge detectors the robot base, 
which when detecting the signal will instruct the robot to move away from the edge; see Chapter 


V, Section C.3 for additional details. 


E. SUMMARY 
The SE 3015 is easily decomposed into the base, optics and weapons. The basic 
parameters of the SE 3015 robot, weapons and projectiles of the weapon have been mapped to 


the simulation through a robot class and matrices. 
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Figure 3.1 Robot Wars playing field 
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IV. ROBOT CONTROL SYSTEM 


The robot actions and reactions to its opponent and the playing field are controlled by its 
computer code. Programmed in Dynamic C (Zworld Engineering, 1995), the code controls 
movements, interpretation of the signal levels received from the eyes, tactics, reactions and 
weapons fire. One of the primary goals of this thesis is to translate the Dynamic C code of the 
robot to the Simbot C++ code, preserving the tactics and actions of the original robot code. This 


section describes the translation process and its integration into the simulation. 


A. TINY GIANT MINIATURE CONTROLLER 

The Tiny Giant Miniature controller 1s a compact miniature controller produced by 
Zworld Engineering (Zworld Engineering, 1993). It consists of a Z180 micro processor with a 
9.216 MHZ clock speed. 256K bytes of EEPROM and 512K bytes of battery packed static RAM 
are available to the student. The Tiny Giant is equipped with a 4-channel analog-to-digital (A/D) 
converter with configurable input amplifiers which can be accessed with a Wago connector. The 
Tiny Giant is programmed using a Dynamic C interface board. The program is transferred from 
an IBM-compatible PC through a Zworld Z485 communications processor card via an RS232 
serial port. The Tiny Giant is capable of operating in a stand-alone capacity once a program has 


been downloaded into RAM. 


B. DYNAMIC C CODE 
The robot code is written in Dynamic C, a version of C tailored for use with the Tiny 


Giant. An IBM compatible PC is required for programming the Dynamic C code. Dynamic C 
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allows for the quick downloading via the serial port and testing. While connected to the 
computer, data from the SE 3015 robot can be printed to the computer monitor. This capability 
1s most often used to check the signal levels obtain from the robot eyes. 

The Dynamic C code for the robot can be written with a variety of different styles to 
include while loops for sequential processing, and costatements for parallel processing. The 
majority of students prefer to use while loops, which will have the SE 3015 perform its actions 
sequentially, looping through portions of the program until a desired condition is reached (e.g., 
the opponent is within firing range). The costatement approach allows for several actions to be 
running at one time (i.e., the robot can look at the same time it is moving.) The simulation 
currently only allows for while-loop sequential processing. Appendix B, provides a sample robot 


code written with while loops. 


C. ROBOT OPERATION 

The robot is controlled by the student-defined program that 1s cross-compiled in Dynamic 
C and downloaded into the Tiny Giant controller. Each program written requires parallel 
input/output data ports A and B (PIODA/B) to initialize the output ports. The PIODA ports are 
used to receive the information from the optical sensors in the form of an integer, currently 
between 16 and 4080 (previous maximum value was 2040). The value 16 corresponds to 
background noise and 4080 corresponds to saturation when the other beacon is immediately in 
front of the photodetector. The PIODB ports are used to send signals into the robot to turn on 


the gun motors and fire the gun. 


Each robot code requires two functions: the platform function, and the interrupt handler. 
The platform function sends the motor control string (an eight character string indicating motor 
direction and speed) to the robot motor to control the robot movement. The SE 3015 robot has 
two powered wheels each of the two wheels has its own motor. The motor control string 
provides the necessary commands for each motor. Table 5.1 provides a description of the motor 
control strings. 

The SE 3015 robot code has an initial one-time set up to initialize variables and 
input/output ports that 1s separate from the primary search and shoot routine that drives the robot. 
This initial portion may also include a small program to move the robot from the starting 
position, usually a corner of the playing field, into a more advantageous point generally in the 
center of the playing field to begin its search. Then the robot typically enters a search routine, 
(generally within a while loop) to search for, locate, move to and fire upon the opposing robot. 
This portion of the program incorporates a sense-decide-act logic loop. The sensing is 
performed by getting readings from the right and left eyes. Decisions are then made based on 
the combined value and the individual values of the eyes as to where the opposing robot is on the 
playing field. The decision also includes the determination as to whether to move closer to the 
other robot or fire upon it. The "act" result is either a motor control string sent to the platform 
faniction to move the robot or a fire signal sent to the weapon. 

At any time (although most often during a movement phase) an interrupt can be sent to 
the program from either the edge detectors or the bumpers. This interrupt will halt the main 
program, execute the interrupt program based on the type of interrupt, then return to the main 


program. In most cases, the main program will resume where it was interrupted, unfortunately, 
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there is a possibility that the interrupt can cause the program to "forget" where it was when 
interrupted. When this occurs, the program may restart at the beginning, return to the top of the 
current loop or reexecute a command that was previously completed. On rare occasions, robots 
have "gone to sleep" for a few moments before continuing. Figure 4.1 shows a simple logic flow 


of an SE 3015 robot. 


D. SE 3015 FUNCTION MAPPING 

The simulation attempts to preserve the robot code as best possible by using the same (or 
similar) functions and I/O calls as the robot uses. This section will show how the function and 
I/O calls are mapped to the simulation. The physical parameters are described in Chapter II, 
Sections B and C. Some components of the robot require only a single function to simulate their 
behavior while others require multiple functions. 

Table 4.1 shows the robot I/O and function calls and variables that need to be directly 
mapped to the simulation from the SE 3015 robot code. Appendix C provides descriptions of 
the robot class and the related functions. This is Dynamic C code that is student programmed 
and then downloaded into the actual robot for the competition. The Simbot code is translated 
from the Dynamic C code for use in the simulation main program; Appendix D provides specific 


details on converting the robot code. 
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end 


Figure 4.1 Sample SE 3015 code logic flow 


ys, 


SE 3015 Robot 


ad_rd(int n) 


outport(PIODB, 0x0a) 


platform( ) 
ie 


count 


description SIMBOT 


I/O call which returns an value from the eyes 
calls the class function optics to calculate the 


ieneilereto ame ores botA.ad_rd(int n, SimbotClass & botB) 


sends an output signal to a component of the 
robot such as the weapon, indicating a signal to 


fire botA.outport(PIODB, Ox0a) 


sends the motor control string to the motor platformA( ) 
botA.platform(SimbotClass & botB) 


character string to hold the motor control string 
sent to the platform function above botA.buf 


counter to determine the length of time 
between motor control string sends to the 
motor 


Acount 





Table 4.1 Code mapping table for SE 3015 code to simbot code 
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The significant different between the Dynamic C code and the Simbot C++ code lies in 
the specification of the function or I/O call toa Simbot. The robot computer is internal to the 
robot and drives the robot based on the Dynamic C code and external input. The SE 3015 robot 
is only aware of its opponent through its sensors. | The simulation computer is external to the 
Simbots and is controlling both at the same time. The simulation computer is aware of the 
parameters of both robots at all trmes. However, the simulation needs to know which Simbot is 
calling a function and which Simbot is the object of the function call (1.e., either Simbot A is 
looking at Simbot B or vice versa). 

The simulation must link the function or variable to the Simbot object by use of the botA. 
prefix attached to the robot class variables and function calls. The exception to this is the 
function platform which is a function inside the main and used to control the simulation flow. 
Each robot must have its own platform function as it has its own robot simulation code function 
(as described in Chapter V Section B) provides a detailed description. The function platform is 
used by both the SE 3015 code and the Simbot code to convey the motor control string to the 
motor. The Simbot function platform then calls a specific class function platform which then 
calculates the robot movements. 

The robot actions and components are mapped on the simulation as shown in Table 4.2. 
The piTober functions shown are all class functions and accessible only through the class 
functions themselves, with the exception of the functions platform, outport and ad_rd8. The 
platform function is called from the platform functions in the simulation main program. The 
outport function is used to interface the parallel I/O data ports and the ad_rd8 function is used 


to obtain the simbot optics signal level. Each of the Simbots instantiated by the main program 
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SE 3015 Robot | description SIMBOT 


motor control 


wheel movement 








breaks the motor control string into 
the specific information for each getVelocity(float w1, float w2) 
wheel 











calculates the movement of the 
simbot over the next time step 





position( ) 
platform(SimbotClass &) 





checks to see if the simbot is at the 
edge of the playing field, determines 
if it is the fore or aft edge and then 

responds accordingly 








edge_detect(float w1, float w2) 





edge detection 
checks to see if the robot has hit and 
obstacle on the playing field and 
then moves always from the obstacle 


bumpers 
encountered. 
the eyes of the robot. The optics 
function computes the Simbot A’s 
photo diodes relative position to Simbot B and 
then returns a signal level to the 
ad_rd8( ) interface 


weapons fire sets the launch conditions and nnfie®) 
position for the projectiles b 
rojectiles computes the flight path and scores .. 


Table 4.2 Component and action mapping for SE 3015 hardware and performance attributes to the simulation robot 
class functions 





bumpers(SimbotClass &, float wl, 
float w2) 





optics( ) 
relative_angle(SimbotClass& bot2); 
range(SimbotClass& bot2) 
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has a set of these functions which can be tailored to the individual Simbot through the initial 
instantiation process. The list of incorporated parameters used in these functions is found in 
ihable.3.5:. 

The additional functions or actions that affect the Robot Wars competition are the scorers 
and referees, shown in Table 4.3. Their actions are part of the robot class and perform similar 
functions but are not a simulation of the specific behavior performed. The auto_ref function 
works to keep the Simbot from leaving the playing field or becoming stuck in the bumper 
routine. The scoring of the Simbots is strictly based on the projectile calculations. Both of 


these functions are missing the human factor and the randomness of their associated behavior. 


E. SUMMARY 

The SE 3015 robot is controlled by the Tiny Giant Micro controller which acts as the 
robots computer. It uses several functions to receive information from its eyes and sends 
information to the robot motor and the weapons. These function are mapped onto the simulation 


robot class functions along with the human referee and scorers. 
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Table 4.3 Additional Robot Wars Competition functions mapped to the simulation robot class functions. 





will move Simbots stuck in the edge 
routine or bumper routine or 
combination there of 








assesses whether or not the projectile 
has hit the Simbot. 
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V. SIMULATION 


The Robot Wars computer simulation is written in a combination of five computer 
languages and is composed of five parts. The simulation flow must allow the Simbots to act 
nearly simultaneously with each other in order to preserve the integrity of the original simulation. 
The simulation manipulates two Simbot class objects which represent the opponents and 
generates two data files containing their position information at each time step. The graphical 
program creates a computer generated animation display from these data files to show the robot 


interactions. 


A. OVERVIEW 

The simulation consists of the main program, the robot simulation code, the robot class, 
the robot data files, and the animation display. The main program 1s written in a combination of 
C++ and UNIX C and is the controller for the simulation. The robot simulation code was 
originally written entirely in Dynamic C for SE 3015 Robot Wars and converted as necessary to 
C++ for the simulation and is contained in the main program. The robot class contains the 
computer simulation of the robot components and is written in C++. The data files are ASCH 
text files created by the robot simulation and used to display the animation in the animation 
mn The animation program is written in a combination of Open GL (Nieder, 1993), 
XMOTIF (McMinds, 1993), and C++ and displays a simple animation of the robot wars using 
primitive forms. Table 5.1 provides a breakdown of these parts which will be discussed 1n this 


chapter. 
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program description number of files/objects 
file generated. 
The main file contains the two sets of the Simbot 
code, platform function and interrupt handler for 
each of the Simbot. Instantiates two Simbot objects 
and two processes. The main controls the 
simulation flow through process handling 


SimbotCode | a function of the main program containing the 
converted Dynamic C code for use to control each of 
Simbot actions/reactions. 


Simbot Class | The Simbot class contains the functions simulating | 2 objects instantiated 
the robots hardware and software 


data file The date files contain the position information of the | 2 files, 
Simbots generated by the main program for use in ( one for each Simbot ) 
the graphics animation program. 


graphics reads the data files and graphical display the robots 1 (plus related 
program and movements through computer generated supporting files) 
animation. 





Table 5.1 Program file descriptions. 


In order to properly simulate the SE 3015 robot war, the program must be able to interact 
with both robots and have them move or act simultaneously or nearly simultaneously. Near 
simultaneous movement is defined as one robot moving a small incremental step, then the other a 
similar sized step, alternately repeating the sequence. These motions must replicate the motions 
as directed by the students robot code used in SE 3015 in order to maintain the integrity of the 
simulation. Each Simbot must be able to obtain the sensor information, optical or contact, on 
the other Simbot in response to the other Simbot’s movement. After a Simbot fires on the other 
robot, the program must be able to determine if the projectile impacts the other Simbot which 


may have moved from its position at time of fire. Additionally, after each step, a Simbot must 
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be able to determine if it has made physical contact with the other Simbot, hit an edge or has 
acquired the other Simbot with its optical sensors. 
In order to obtain this near-simultaneous movement while preserving the students’ 

original code, UNIX C commands were used to create a separate process for each of the Simbots. 

Each Simbot code function 1s a process of the main program. The processes control the 
Simbots movement on the playing field and through its own Simbot code. The main program 
must be able to track both Simbots place within their respective codes, and when exiting one 
Simbot’s code must be able to return to the other code where it had previously left. If the main 
program does not know where it last left a particular Simbot code, it will start at the beginning of 


the function each time it returns. The simulation main code is found in Appendix D. 


B. SIMULATION PROGRAM COMPONENTS 

1. Main Program 

The main program uses UNIX C to create two separate processes, one for each of the 
Simbots, and a sharing routine. The main program controls the sharing of the two Simbot 
processes and the master clock. The Simbot movements are controlled in the Simbot simulation 
code and the Simbot class. The main program instantiates two Simbot class objects that will 
sii the actual robots. The program uses the UNIX C commands blocproc and unblocproc 
to hand off control to the two Simbots. The program terminates when the master clock reaches 
the simulation-end time, set at the start of the program. 

The command blocproc blocks the current process and allows the computer to return to 


the main program to get the next instruction. The command unblocproc allows the next process 


Ze) 


to begin. Only one process may be active at atime. The processes are assigned their own 
process identification that the control uses to identify which is active and which is asleep. 

The master clock count, although not a one-for-one ratio with seconds, can be thought of 
as approximately the number of seconds to run the simulation. A clock count equals one 
movement of the robot on the playing field. All logic decisions, sensor readings, and weapon 
fires will be considered as instantaneous events in this simulation. At the completion of the 


simulation, the main program displays the Simbot scores. 


2. Robot Simulation Code 

The robot simulation code contains the student’s Dynamic C code converted to C++, and 
the modified platform function and interrupt routine. One set of the functions is created for 
each of the Simbots and placed in the main program. Each Simbot has three functions within the 
main program. A minimal amount of modification is done to the Dynamic C code by the student 
to conform to C++ for use in the simulation. Conversion details are provided in Appendix E. 

The platform call in the robot code requires further explanation about its conversion 
from Dynamic C to C++. In the Dynamic C code, the platform function is called and then 
followed by an empty "for loop" to delay any further platform calls until the robot has had a 
chance to handle the first platform call. For example, the robot’s microprocessor requires a 
certain amount of time to properly handle the motor control string sent to it via the robot code. If 
motor control strings are sent too close together, the robot will not be able to process the string 


properly, resulting in a timing error that may hang up the robot microprocessor. This, however, 
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does not pose a problem for the Simbot, where new motor control strings can be sent 
immediately after each other. 

With the actual robot, the motor control string is sent by the platform to the motor. The 
robot then moves according to directions indicated by the motor control string for the duration of 
the “empty for loop" and until a new motor control string is sent to the motor. This is not the 
case with the simulation. Since the simulation is written in C++, most compilers will optimize 
the empty for loop and will not run it as a delay. For example, the code line below 

for (count = 1; count < 1000; count++); 
is a null statement and will become 

count = 1000; 
after being compiled. Initial tests of the Dynamic C program, as written for SE 3015, in the 
simulation had the Simbot making one incremental move based on the first motor control string, 
ignoring the empty for loop and proceeding to the next motor control string and platform call. 
So, instead of going forward for a count of 100, the Simbot went forward for a count of only 1. 
Changing the order of the "for loop" and the platform call in the simulation, Figure 5.1, forces 
the simulation to make successive platform calls based on the old motor control string, not 
allowing the simulation to proceed to the next motor control string until the delay has been 
simulated. For example, the actual robot would send one motor control string, act on it and then 
counts to 100 while moving in accordance to the control string before continuing with its code. 
In the simulation the robot is sent the motor control string once but calls the platform function 


100 times, making one incremental move per function call. 
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code fragment for Dynamic C robot code 
strepy(buf, 'fferffgr''); 
platform(); 


for(count = 1; count < 1000; count++); 


modified code fragment for use in simulation 


strepy(bot.buf, "ffgrffgr") 
for (bot.count = 1; bot.count < 1000; count++ ) 
platform(); 





Figure 5.1 Platform function call sequence translated into C++ 


The simulation platform function calls a specific Simbot class function assigned to a 
Simbot. It is within these class functions that the actual movements and the interaction between 
Simbots are calculated. In most cases the robot code is modified by added a botA. or botB. 
before all YO commands. POIDA(0x12) becomes botA.PIODA(0x12) in order to access the 
correct Simbot class functions. The platform function call is changed to either platformA or 
platformB depending upon the Simbot. The platform function is modified from the original 
platform function used by the student to call the class platform function and to handles the 


process control. The platform function writes the position information to the data file. 


3. Simbot Class Functions 
The Simbot class is used to simulate the robot hardware. It is composed of a set of 
generic movement, projectile, and optical sensor functions. These functions calculate the actual 


movements, sensor reading and projectile trajectories. The functions can be modified to better 
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simulate the individual robots by hard coding the changes into the simulation by use of virtual 
function designations. Each function is discussed in Appendix C. 

The interrupt routine is overwritten as a class function called edge_detect and is linked to 
the robot class. The response to the forward or aft interrupt is not altered from the students 
original logic only how it determines the interrupt. This new edge detection routine is called by 
the Simbot class platform function as part of the new position calculation. The bumpers are 
handled within the Simbot class with a universal routine to be used by all instantiations of the 


Simbot class. 


4. Data Files 

The Robot Wars simulation generates one data file for each Simbot. The data file 
contains, the time count, the Simbot color, the x and z positions of the Simbot on the playing 
field and a fire flag designating whether or not the Simbot has fired a projectile. The fire flag is 
either a O for no projectiles in the air or a 1 for projectiles in the air, this is used to allow the 


graphics program to change the Simbot color when it has fired a projectile. 


C. 3D GRAPHICS PROGRAM 

| This program is an XMOTIF/OpenGL program written to display the Simbots on the 
playing field. The program uses primitives to show the playing field, Simbots, and projectiles. 
The program reads in the information from the data files to draw the primitive shapes 
corresponding to the Simbot movements determined by the data. The simulation allows the 


display of the entire Robot Wars or selected portions by indicating the start and end times. The 
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simulation allows for different viewing angles of the robot wars in progress. A single light 
source is used with no texture mapping to allow for near real time simulation speeds. The 
simulation can be sped up or slowed by controlling the floor pattern. The single square pattern 
on the floor will run the program at its fastest speed while the checkered floor will result in slow 
motion. 

The animation portion was kept separate from the rest of the simulation to better allow 
for display improvements. Using data files that are not platform specific, the animation display 
can be written in any language that will support reading ASCII text files. In the future the 


animation portion may be modified to allow for display over the internet. 


D. ROBOT WARS SIMULATION FLOW 

The flow of the simulation execution is shown in Figure 5.2. This flow simulates the 
constant interaction between the two Simbots on the playing field. Unlike the actual SE 3015 
Robot Wars, each Simbot will know the position of itself and the other Simbot on the playing 
field. The following details the interaction between the main program, the students robot code, 


the robot class and the data file creation. 


1. Initialization 
The program starts with the instantiation of two robots, botA and botB and two 
processes. Each of the Simbot’s code is a designated processes, assigning processA to 


simCodeA() and processB to simCodeB(). The simCode is the function while, the process is 
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Figure 5.2 Simulation flow 
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the actual performance of the Simbot code. The master clock count is designated by the user 
and will determine the duration of the simulation. 

2. Start Up 

Simulation start up requires that each process start at the beginning of its simCode and 
exit when it reaches its first Simbot class platform call, but before it makes it first movement. 

The processA will initiate the beginning of the simCodeA and work through the code 
until it reaches a platform call, platformA( ), the process then blocks itself and unblocks 
processB. This occurs before entering its specific Simbot’s platform function, botA.platform(Q) 
to calculate its first move. It is important to note that processA exits from platformA( ) vice 
simCodeA where it first entered to facilitate the hand off to ProcessB. ProcessB will repeat the 
same steps as processA, exiting through platformB( ) and returning to the main program after 
blocking itself and unblocking processA. The main program then starts the while loop. 

3.The While Loop 

The while loop will repeat the hand-off between processA and processB for the duration 
of the count designated by the master clock. The simulation will then step through the Simbot 
code, determining the Simbot’s actions in accordance with the simCode and reactions to the other 


robot and playing field boundaries. 
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ProcessA( ) starts by returning to the platformA( ) function and then follows the steps 
below. 
step a: platformA() and enters botA.platform() to calculate its incremental step. 
botA.platform( ) will make additional function calls to other class functions. 
The class functions will convert the motor control string into angular velocities, 
determine if the Simbot has hit an edge or the other Simbot and determine the 
necessary reaction, and calculate its new position before returning to platformA(). 
step b: The process returns from botA.platform( ) to platformA() and all new position 
data is written to the related data file. The process then returns to simCodeA(). 
step c: The process returns to the simCodeA() to just after it had made its last platform 
call. The process then works through the simCode until it reaches its next 
platform call. _ Only movement instructions are considered a time step, all other 
decisions or I/O calls are considered instantaneous. 
step d: The platform function call then returns the process back to platformA. At this 
point, processA blocks itself and unblocks processB, returning to the main 
program. 
The main program starts the same series of steps with processB. Upon return from 
processB, the while loop checks to make sure the master clock count limit has not been reached. 


If not, the loop begins again with processA. 
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4. Conclusion and Clean-up 
Once the master clock count limit has been reached the program exits the loop. The final 
score 1s displayed and written to both the position data files. The processes are terminated and 


the program exits. 


E. SUMMARY 

The multiple process method was used at the expense of program portability in order to 
preserve the students robot codes and allow near simultaneous movement on the playing field. 
By using the multiple process technique the Simbots will interact with each other in a fashion 
nearly identical to that of the actual robots. The simulation creates the data files which are used 
by the graphical display or animation program. From these data files, the simulation can be 


designed for display in other graphic languages. 
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VI. ROBOT BASE 


The goal of the movement simulation is to simulate proper physical reactions to the 
student code determined motion of the SE 3015 robots. The robot is passed a motor control 
string from the code to the motor controller which must decipher it and then act upon it. The 
robot must also handle the interrupts to its code that are caused by edge detection and the 
bumpers. The Simbot simulation code must perform similar tasks. Unlike the SE 3015 robots, 


however, the Simbots lack such problems as weight, friction and acceleration. 


A. MOTOR CONTROL STRING 
The robot motors are controlled by a motor control string set through the serial 
communications buffer. Three code lines control this operation. 


1. ser_init_z1(0, 9600/1200) - sets up the appropriate serial communications buffer 
2. outport(ENB485,1) - enables the 485 driver 
3. ser_send_zl(buf, &cc) - sends the motor control string, buf, to the 
communications buffer. The string length 1s cc. 
These code lines are found in the platform function that is general to most programs. The 


platform function 


platform () 
{ 


cc = sizeof(buf); 
outport(ENB485, 1); 
ser_send_zl(buf, &cc); 
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is provided to the student by the course instructor. The variable buf is an 8 character string that 
contains the instructions for the motors, example "ffgrffgr" which tells both motors to go forward 


at speed 15. Figure 6.1 provides further details on the motor control string breakdown. 


Motor Control String 
Robot receives a motor control string to control its direction and speed. The 
sting is 8 bytes long and is broken down as listed below. For example control 
string "fferffgr" indicates both motors to go, rotate, forward at speed 15. 


fferfigr 


Ist byte left wheel speed (hexidecimal values 0-f corresponding to 0-15) 
2nd byte left motor direction (f = forward, r = reverse) 

3rd byte left motor status (g = go, s = stop) 

4th byte left distance counter(generally not used) 

5th byte right wheel speed (hexidecimal values 0-f corresponding to 0-15) 
6th byte right motor direction (f = forward, r = reverse) 

7th byte right motor status (g = go, s = stop) 

8th byte right distance counter(generally not used) 


The robot code sends this to an internal motor function by use of string copy 
to a buffer string via the platform function. The motor function breaks down 
the string as listed above and sends the direction and speed information to the 
left and right motors which will then turn the robot wheels. The functionality 
can occur any place in the robot program and as often as needed, however, if 
two strings are sent too close together they will "confuse" the robot and 
possibly cause it incorrectly execute the string. 





Figure 6.1 Motor Control String Breakdown 


The sending and receiving of these strings is interrupt driven on board the robot and will 
operate in the background while the program is doing other things. The information is passed by 
pointers, buf and cc, to a counter and a buffer. The serial port reads in the data one byte at a 


time as determined by the string length, cc, which decrements as each character of the motor 
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control string is passed to the motor controller. The port reads in the data until it counts down to 
zero. Interrupt routines change both the counter and the buffer. It takes a finite amount of time 
for the communications port to send the information. If a function is called before the data 
transfer is complete it can cause the previous platform function to be ignored and thus affect the 


robot’s motor function, probably adversely. 


B. THE PHYSICAL ROBOT 

1. Robot Base Description 

The robot is composed of a cylindrical body made of PVC material with two hard plastic 
wheels mounted at the bottom. Balance is provided by low-drag plastic bumpers at opposite 
sides of the robot. The robot wheels are powered by a 12 V battery and the wheel motors are 
controlled by the robots code. The robot code sends a control string to the motor directing the 
wheels to rotate forward or reverse at an incremental speed from 0-15 (Figure 6.1). 

The robot base is provided to the student by the course instructor. Each student’s base is 
nearly identical, with only minor differences due to manufacturing variability. The base is 
approximately 12 3/4 inches in diameter and 4 inches high. The wheels are 3 inches in 
diameter, set parallel to each other approximately 9 inches apart, Figure 6.2. Two rubber 
stoppers, each approximately 1/4 inch high are mounted fore and aft on the robot’s center line to 
help maintain the robot balanced on its wheels. 

As per the SE 3015 robot competition rules of February 1996, robot height is restricted to 
4 feet tall and a weight of 35 lbs. The weight of the robot and positioning of the weapons 


systems on it can effect the robot performance, such as decreased speed and drag or friction 
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degradation the robot’s performance. When the upper weight limit is reach and the robot’s 
components are not properly centered, the robot will be resting on one of the rubber stoppers, 


which will impair its motion. 


rubber 
stopper 


edge 
dectector 





Figure 6.2 Robot base undercarriage 


2. Bumpers 

The robot’s bumpers consist of two long contact switches mounted across the front and 
back on the bottom edge of the robot base (Figure 6.3). The bumper contact switches are 
activated when the robot runs into an object on the playing field or into the opponent robot. 
When activated, the robot’s motor controller will interrupt, or override, any current motor-control 
strings and move away from the other object based on which bumper has been activated, either 


forward or in reverse. The bumper routine is hard coded into the robot motor controller and 
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cannot be changed by the student, therefore each of the robots will react in a similar fashion 
when a bumper is activated. If the forward bumper is activated, the robot moves backward away 
from the object, if the aft bumper is activated, the robot will move forward away from the object. 
This is discussed further in section D.4. After being bumped, the robot will move at its 


maximum speed, 15, for approximately 1 1/2 to 2 feet. 
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Figure 6.3 Side view of robot base 


3. Edge Detection 
| The robot uses an electronic edge detection system provided by the course instructor. 
The playing field is ringed by an wire emitting aradio signal. The wire ring is set 
approximately 4-6 inches in from the edge of the playing field on all sides. The robot has two 
small edge detectors mounted on the underside of the base near the rubber stoppers, Figure 6.2, 


that will detect this signal. The detection circuitry, although provided and mounted inside of the 


43 


base must still be fine tuned with a sensitivity trimpot. It is possible for the student to set the 
sensitivity to a point where the robot will not detect the signal and run off the playing field, or to 
set it too high where 1s reacts before it physically approaches the edge. 

Although each student can write their own robot’s reaction to the edge detection, in 
general, the robot will back away from the forward edge detection and move forward away from 
the aft edge and perform a subsequent maneuver. The edge detection is handled by the robot’s 
software by using interrupt flags, functions and routines. 

The following pieces of code are used by the robot for edge detection. 

1. #INT_VEC PIOA_VEC INT1 - is used at the start of the program to set up the 

interrupt handling/interaction between the hardware and software. The first part, 

#INT_VEC, expansion bus attention INT1 vector, directs the interrupt to a user 

function in Dynamic C. PIOA_VEC refers to the PIO parallel port channel A and 

INT 1 is the expansion bus attention line interrupt. 

2. interrupt reti INT1() - is for a user defined Dynamic C interrupt function that 

the first code line vectors the interrupt to. The robot’s reaction to the edge 

detection on the playing field is student programmed. 

3. inport(PIODA) - this YO command returns an integer value that indicates 

whether the forward or aft edge detector has been triggered. 

4. EIQ - is a Dynamic C library function call to reset the interrupt vector. 

As the robot code is running, it is continuously checking for the interrupt signal. The code lines 
are placed at different places within the robot code and are essential to the proper handling of the 


interrupt function. 
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4. Calibration Problems 

The robot wheels theoretically rotate at the same rate when given the same speed and 
direction commands. However, students have observed on occasion that one wheel moves at a 
slightly different speed than the other, with the difference speed dependent. It is possible to use 
the built in trimpots in the robot base to make the wheels rotate at the same rate for a certain 
speed but this cannot be achieved for all speeds. If at the highest speed, 15, the robot curves 
slightly to the left, the student can adjust the robot’s trimpot until the robot moves in a straight 
line at this speed. Unfortunately, the student will then observe the robot curving slightly to the 
right at lower speeds. The difference in speeds can be compensated for by adjusting the robot 
motor control strings to eliminate long movements. 

The change in speeds from -15 to 15 in each wheel is not linearly incremental. 
Although each speed is indicated by an integer, the difference between speeds is not. The 
change in speed between | and 2 is not the same as between 2 and 3 and speed 4 1s not 


necessarily twice as fast as speed 2. 


5. Battery 

The robot uses a single 12 V battery to supply power to the motor and computer, and 
optionally this battery can be used to power the optical and weapons circuits. The battery must 
be continuously charged to maintain the full charge necessary for proper operation of the robot. 


If the battery becomes too low, the robot may perform poorly or not function at all. 
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C. SIMULATION MOVEMENT 

1. Simulated Robot (Simbot) 

The Simbot is generated in C++ and visualized (i.e., animated) using OPENGL/XMotif. 
The Simbot is scaled to the robot at 100 units in diameter and 250 units tall. The Simbot is 
consider perfectly balanced, and friction and acceleration are ignored. The Simbot moves ina 
two-dimensional playing field, grid size 1600 by 1600 units in the X, Z plane where the angle of 
the Simbot’s rotation is measured clockwise from the Z axis, Figure 6.4. For ease in creating the 
initial simulation each incremental move is one time unit and each incremental move is 
calculated in grid units. 

The Simbot wheel radius and distance between wheels was set at a ratio of 0.25 to 1. 
With these measurements a Simbot moving at the max speed of 15 will move 15 grid units per 


time unit or if rotating on axis at this speed will rotate at 15° per time unit. 


2. Motion 

The actual movement of the Simbot is calculated by Equations 6.1 through 6.6. The 
incremental angle of rotation for the Simbot is calculated via Equations 6.1 through 6.3, using the 
angular velocities, ®, and @,, obtained from the motor control string, the radius of each wheel, r, 
and r,, and the distance between the two wheels. The total rotational angle, 0, of the Simbot is 
found by adding A® to previous total angle 0. For the purposes of this initial simulation, the 


radii of the wheels are assumed the same. 
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v=Oor (6.1) 


2 a 
a 2 (6.2) 
d 
eae. 0, (6.3) 


The linear velocity of the robot is calculated by Equation 6.4. 





(6.4) 


The incremental movements in the x and z plane are calculated from Equations 6.5 and 6.6 using 


the total rotational angle 0. 


Ax = vt cos 0 (6.5) 
Az = vt sin 0 (6.5) 


3. Bumpers 


Currently, the robot wars simulation is not designed for objects/obstacles on the playing 
field other than the two robots. A hit on the bumper and the subsequent reaction has the highest 
priority on the robot’s operation. When moving the robot must respond to a bump before an 
edge detection and before acting on the current motor control string instruction. The response to 


the bumper is essentially the same for each of the robots and the response is not programmable 


by the student, as can be done for edge detection. 


47 


The bumpers are simulated by checking one Simbot’s location on the playing field 
relative to the other Simbot. Since each Simbot is 100 units in diameter, if the range between 
the two Simbots is less than 100 units, then the Simbots have "bumped" into each other. As part 
of calculating its position on the playing field, the Simbot checks to see if it has run into the 
other Simbot. At that point it will know that it has hit the other Simbot with its front bumper if 
it is moving forward or its aft bumper if it is moving backward. The simulation will then pass a 
flag to the other Simbot to indicate that it has been bumped. The relative direction of the guns 
of the two Simbots will determine which of the opponent Simbot’s bumper has been hit, as 
shown in Figure 6.4 and 6.5. If the two robots are facing each other or both are facing away 
from each then both will have hit the same bumper, both forward, Figure 6.4, or both aft 
bumpers. If one 1s facing opposite the other then the opponent Simbot will have been hit on the 
opposite bumper, as shown in Figure 6.5. Once bumped, both Simbots will begin to move away 
from each other in a direction opposite the hit bumper. 

If the bumper of a stationary robot is hit, the robot will move away from the hit at its 
maximum speed for about afoot. This translates to a speed of 15 for a count of 10 1n the 
simulation . In the case of the impact of the two robots, the effects of a collision have to be 
accounted for. For the simulation, the collision will be considered elastic with both robot of 
equal masses. If the collision are perfectly elastic, both Simbots after collision at velocity 15 
would each move away at velocity -30, however, the maximum velocity of the robot 1s limited by 
the motors. In the simulation, the speed of the bumper routine is limited to 15. Full analysis of 


the collision effects on the bumper routine 1s left to future research. 
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Figure 6.4 SimbotA’s fore bumper will hit SimbotB’s fore bumper. 
After impact both Simbots moves backwards. Arrows indicate direction 
of travel before impact. 





Figure 6.5 SimbotA’s fore bumper will hit SimbotB’s aft bumper. After 
impact, SimbotA moves backwards and SimbotB moves forward. 
Arrows indicate the direction of travel. 
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4. Edge Detection 

The Simbot will detect the edge of the playing field in a manner similar to the actual 
robot. It is when the edge detector crosses edge of the playing field that the robot will detect an 
edge and respond according to the response programmed by the student. Robots may have 
different responses to both the fore and aft edge detectors. Generally a robot will respond in a 
fashion similar to its bumper response. 

The most-used version of the edge-detection interrupt routine in the actual robot wars is 
for the robot code to immediately enter an edge-detection routine after the edge has been 
detected. In this case the robot will interrupt its current movement and move in accordance 
with the preprogrammed response. A typical response to the edge detection is: for aft detection 
to move forward away from edge and for fore detection to back up and turn to face away from 
the edge. 

The simulation 1600 x 1600 unit playing field has an edge detection ring 50 units in on 
all sides, reducing the playing field to 1550 x 1550 units, see Figure 6.5. The forward and aft 
edge detectors are points on the central axis at the front and rear of the robot 5 units back from 
the edge of the Simbot. The edge detection sensitivity can be simulated approximately by 
changing the location of the edge detection points. Moving the edge detection points closer to 
the center of the Simbot, the Simbot not detecting the edge until it is almost on it. Moving the 
edge detection points outside the Simbot edge, will make the Simbot more sensitive to the edge. 
As with the robot, speed and other factors such as interrupts from the bumpers can cause the 


Simbot to fail to detect an edge. 
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D. AUTOMATED REFEREE (AUTO REF) 

Although most of the robot’s problems dealing with motion are ignored or avoided, the 
simulation experiences complications that affect the actual robots. The Simbots are capable of 
going off the playing field by ignoring an edge-detection or getting hung up, either alone or in 
pairs, on the playing field edge. As the simulation is run in C++ without visualization, an 
automated referee has been added in an attempt to get the Simbots back on the playing field. 

The Simbot is generally more reliable than the real robot in detecting the edge but such 
things as a bumper interrupt may cause it to run off the playing field. If this occurs the auto ref 
will place it back onto the field near where it left. This correction is determined in the function 
checkposition( ) which act like an edge detection and checks to see that the Simbot has not run 
off the field and makes the corrections as previously discussed. When placed back on the 
playing field, the Simbot can reevaluate the edge detection and then respond accordingly. 

The case of the Simbot getting “hung up" on an edge is more complicated as it may 
involve the other Simbot. Both the edge detection and bumper interrupt functions use a 
separate counter to determine the length of the Simbot’s response. If another edge or bumper is 
encountered before the first routine 1s complete, the Simbot will start the new routine and will set 
an internal flag to indicate that multiple interrupts are occurring. The auto_ref( ) function 
checks for more than three bumper routines or a combination of more than five bumper and edge 
detections in succession. If this criteria has been met, auto_ref() function will alter the 
Simbot’s directions slightly to break them out of the multiple interrupt routines. 

Interrupt hang-up situations that will not be corrected by this function are where the 


Simbot exits the bumper or edge detection routine completely and then immediately enters the 
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routine again. In order to achieve this situation with the bumpers, both Simbots, since there are 
currently no obstacles on the playing field, must approach each other on a straight path at angles 
180° apart and be"locked" into that same path (moving back and forth toward each other). 
However, since ramming the other robot is not a scoring possibility and is not a recommended 
tactic, this situation although possible 1s deemed unlikely and ignored. The second case is the 
Simbot "walking" along the edge. During the SE 3015 Robot Wars Competitions held over the 
last two years it has been observed that the referee has not interfered in this case unless the robot 
rolls off the edge or becomes stuck in one location. Based on that observation, the case of "edge 
walking" will also be ignored as this scenario 1s generally "corrected" when the robot enters a 


corner, observes the other player, or is bumped. 


E. SUMMARY 

The simulated robots will compete on a playing field scaled to the field of the SE 3015 
robot wars competition. With friction and acceleration ignored, the simulated robots still lack 
the realism found with the SE 3015 robots. The simulated robot wars is designed at this point to 
give the student a feel for how their robots will respond to its programming. Aided by an 
automated referee, auto ref, the simulated robot competition will be able to handle some of the 


basic movement problems encountered by the SE 3015 robots. 
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Vil. OPTICS 


The robot uses a pair of photo detectors (refered to as "eyes") to see the beacon on the 
opponent robot. The eyes are connected to a pair of circuits tuned to detect the beacon 
frequency of the opponent robot and return a value corresponding to the amount of light detected. 
The two eyes are mounted above the robot’s own beacon and are set with a divider (referred to as 
a nose") between them which permits left and right angular discrimination. The angle at which 
the robot sees its opponent will determine the amount of light reaching the eyes and values 


returned. 


A. BEACON 

In order for the robots, to detect each other each are equipped with an LED beacon that 
transmits a 360° signal at a unique frequency. The robot optical circuit is designed to detect the 
assigned frequency of the beacon. The current SE 3015 beacon, Figure 7.1, emits light in a 
uniform 360° distribution pattern in the horizontal plane. The beacon transmits a set frequency 
with an approximate 10° vertical spread. Each robot has its own beacon frequency and the 
optical circuit is tuned to detect this frequency. The robot’s beacon is placed on the opponent 
robot for detection at the time of the competition. 

The beacon is mounted underneath the center of the top deck disk, 4.56" above the top of 
the robot base. The photo-detectors are mounted on the top of the top deck above the beacon. 
The beacon is mounted so that only the four thin cylindrical platform support posts obstruct it. 
These four support posts provide minimal obstruction to the beacon signal transmission and are 


considered a negligible obstruction and are ignored in the simulation design. 
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Figure 7.1 Side view of robot with beacon in place showing 10 degree angular spread 
(Hofler, 1997) 


B. THE PHYSICAL EYES 

The robot optical detection systems are designed to detect a specific frequency for which 
they have been tuned. These eyes will detect the frequency transmitted by the beacon on the 
other robot and determine the intensity of the received signal. The circuit is designed for a high 
maximum for the Q value to minimize the noise and interference caused by other light sources. 

The eyes are made up of a pair of photo-detectors, mounting apparatus and a pair of 
optical detection circuits. The photo-detectors used have an active area of 0.17 cm*. They are 
mounted with a divider plate between them to allow for discrimination between the left and nght 


eyes (Figure 7.2). With this divider, the eye on the near side will receive the full signal, but 
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the other eye will only receive a portion based on its viewing angle. See discussion on viewing 


geometry appears in Section C. 
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Figure 7.2 Photo-detector pair with nose 


Interference and noise contribute to detection errors. An AC-coupled RC-bandpass filter 
circuit, Figure 7.3, minimizes the interference caused by the fluorescent room lights. 
Additionally, each eye may have its own separate circuit to minimize cross-talk interference 
between them. The circuit design allows for a relatively high Q , resulting in the robot easily 
detecting the opponent within the confines of the 16 x 16 foot playing field (as shown in Figure 
3.1). Due to the high sensitivity, the eyes become saturated when the beacon is closer than a 


few feet. 
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The eye circuit is generally powered by two nine-volt DC batteries, which must be fully 
charged for proper perform »nce. As the batteries begin to drain, the Q can decrease giving 
erroneous detection values due to reduced discriminating of the beacon signal from other 


external light sources. 
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Figure 7.3 Optical circuit for SE 3015 robots. This is “a useful variant of the state-variable 
bandpass filter. The bad news is that it used four op-amps; the good news is that you can adjust 
the bandwidth (i.e., Q) without effecting the midband gain. In fact both Q and gain are set with a 
single resister each. Q, gain and center frequency are completely independent and are given by 
these simple equations” listed above (Horowitz, 1989, p.278) 
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C. VIEWING GEOMETRY, LEFT AND RIGHT DISCRIMINATION 

The capability for left and right discrimination is one of the more crucial features of the 
robot’s optical system since it 1s required for targeting. The robot cannot know where it 
opponent is on the playing field relative to itself without being able to make this discrimination. 
The left and right discrimination allows the robot program to determine both the approximate 
distance of its opponent on the playing field and where its opponent is in relation to itself. In 
order to produce discrimination, a divider is placed between the photo-detectors to limit the 
directions of light reaching each eye. Without this, both eyes would receive the same amount of 
light regardless of where the robot was within the 180° viewing area. The ratio of the nose 
height to the width of the eye determine the limiting angle, or cut off values, for left and right 
discrimination. The eye widths are measured from the outer edge of the photo- detector to the 
nose for each side (Figure 7.4). 

The limiting angles, Equations 7.1 and 7.2, are calculated using the arc tangent function, 


where « is the limiting angle for the left eye and B is the limiting angle for the right eye. 


R 
I 


Ww 
arctan 7 Cel) 


RH 
I 


Ww 
arctan re (72) 


oy 


The longer the nose is the smaller the limiting angles. With large limiting angles and the robot 
will not be able to discern left from right, and if the angle is too small the robot will only be able 


to see out of both eyes when the opponent ts directly in front of it. 





Figure 7.4 Photo-detector geometry 


The opponent (Figure 7.5) is located on the left side of the robot and thereby in full view 
of the left eye. If angle from center line, y, is less than the right limiting angle, B, then the right 
eye will be able to detect the opponent as well. The fraction of the photo-detector active area is 
determined by Equation 7.3, where y relative angle of the Simbot’s gun to the opponent and @ is 


the limiting angle (a or § depending on which side the opponent is on). This fraction is 


58 


corresponds to the amount of light from the beacon that falls on the partially obscured eye. The 
full signal level is multiplied by this fraction to obtain the simulated signal level of the partially 


obscured eye. 





fraction = 1 - Y ‘7 (23) 
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Figure 7.5 Geometry of sensor reference system 
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D. SIMULATION OPTICS 

Although the optical circuit uses the specific gain, Q and detection limits for the robot, 
the simulation only uses the detection distance and the maximum detection values are used in . 
The simulation has essentially an infinite Q (1.e., there is no sensitivity to range). The placement 
of left and right eyes are not considered identical as they have a direct impact on the robot’s 
targeting ability. 

In order to generate this first simulation of the robot’s eyes, several basic assumptions on 
their performance will be made concerning the optical system and the beacons. The simulation 
does not allow for interference, electrical noise or battery drain. However, the simulation user 
will still have to provide the saturation value, saturation distance and dimensions of the nose and 
eyes. 

After completing the eye circuit and while designing the robot code, the student considers 
the robot maximum eye value obtained and the physical distance for saturation of the eye circuit. 
The maximum eye value is a function of the circuit and is either 2040 or 4080 depending on the 
circuit design. The saturation distance for each robot is a function of the Q and is approximately 
3 feet. The background value observed by the eyes when the beacon is not in sight is 16. The 
maximum distance that the robot needs to see is the diagonal of the playing field, approximately 
22 feet. These are the initial values used in this simulation. The Simbot class function setEyes, 
presented in Appendix C, allows for the eye values and photo-detector geometry to be set for 
each of the Simbots. 

In order for the Simbot eyes to function similarly to the robots eyes, the photo-detector 


geometry has to be determined and entered into the simulation using the setEyes function. The 
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three measurements should be to the same degree of accuracy and must be in the same units. The 
simulation use the measurements in a ratio and the specific units are not important. 

The LED used in the beacon, described in Section B, distributes light spherically, Figure 
7.6. The beacon housing used, limits the light to a 10° vertical spread. A theoretical spherical 
distribution with a 1/r’ fall off is used to simulated values. The amount of light seen by the 
detector is dependent on its field of view and the solid angle of the light from the beacon as 


represented in Equation 7.4. 


= P re background (7.4) 


detector source OQ 


Where is the solid angle on the detector and Q is the solid angle of the light leaving the 
beacon. The 10° angular spread of the beacon translated to a solid angle of 1.096 steradians, 
very close to 1 steradian. The active area of the detector is a constant size and much smaller than 


the °Q. The curvature of the lens of the detector is ignored. 
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Figure 7.6 Angular spread of beacon light 
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Attenuation and the optical efficiencies of the LED and the photo-detectors contribute to 
the degradation of the eyes but will not be considered in the simulation at this time. The 
background value is the point where the circuit is unable to distinguish between the circuit noise, 
interference from other light sources, and the beacon. This value is a constant for a given 
circuit but may change due to the circuit design and individual circuit construction. 

The above considerations lead to the following development for the eye signal levels. 


The spherical distribution, Equation 7.5, was selected to simulated the eye signal levels, S.,. that 


eye 


would be obtained by the Simbot’s optics. 


K 
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The parameters of a eye signal level of 4080 at 3 ft and a background value of 16 were 
entered into Equation 7.5 to obtain a value of 38578 for k. Equation 7.6 is used to determine the 
value for the eye in full view of the opponent and Equation 7.6 1s used to obtain the theoretical 


value for the for the partially obscured eye. 





_ 36578 
S full Ea _ + 16 (7.6) 
eye frac a ea oalk)as fraction eT) 
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The fraction value is calculated from Equation 7.1. 
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E. INTEGRATING EYE SIGNAL LEVELS 

The SE 3015 robot receives the eye values through a function call to an I/O port through 
an analog-to-digital (A/D) convertor . The Simbot will receive its eye values for a similar 
function call. The returned value in both cases will be an integer between the minimum, 
(currently 16) and the maximum (4080) allowable eye values. 

The robot obtains the eye values from the optical systems by a manufacturer-provided 
Dynamic C code function call ad_rd8(int n) which returns an integer value. The function 
parameter "int n" indicates which eye to obtain a value from. The number of eyes that the robot 
can have is hardware dependent. However, most students use only one set of eyes and with n 
equal to 0 or 1 to indicate the left or right eye respectively. 

The simulation function call botA.ad_rd8 (int n, simbotClass &botB), also returns an 
integer value to indicate the intensity level seen by the simulated eye. The simulation function 
call however, requires additional information to obtain this value. The function call must be the 
specific class function assigned to the Simbot, botA, and it must be able to have access to the 
location of the opponent, botB. The simulation assumes only one set of eyes are in use and that 


the left eye is indicated by n = 0 and the night by n= 1. 


F. SUMMARY 

The simulated eyes provide values to the simulated robot as the optical system provides 
the values to the actual robot. The geometrical configuration, essential for left and nght 
discrimination has been incorporated into the model, a critical factor for targeting of the 


opponent. The simulated eye function artificial ranges set at 3 feet for saturation, eye value 4080 
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and the eye background value of 16 and values are simulated using a spherical distribution 


pattern. Noise, and interference are not incorporated into this model. 
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VU. WEAPONS 


This section discusses the "standard gun" used by the student, alternative weapons, the 
ammunition used, and how they are incorporated into the simulation. The current SE 3015 
course has incorporated a standard gun to "level the playing field" allowing students to 
concentrate on other portions of the robot design. The requirement for the use of a standard gun 
varies with each SE 3015 class as well as the number of weapons allowed. This section briefly 
discusses the possible types of weapons systems, but the simulation currently only allows for the 
use of projectile weapon systems. 

In order to properly simulate a weapon system, its dynamics and kinematics must be fully 
understood. Additional considerations include simulating problems such as jammed weapon's 
barrel, failure to fire, and double rounds where two rounds are fired at one time without enough 
energy to propel them both. 

Three basic types of weapons have been used the last few iterations of the SE 3015 Robot 
Wars Competition: projectiles, catapults and obstacles. The standard gun is a projectile weapon 


and will be discussed first. 


A. STANDARD GUN 

The standard gun, Figure 8.1, shoots a 0.5" wooden ball from a solenoid triggered gun. 
This weapon was first used in March 1996, to help equalize the weapons component of the 
competition and allow the student to concentrate on other robot components. The next 


iteration of the SE 3015 course allowed students to use other weapons in addition to the standard 
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gun. Multiple weapons types have been allowed, but the simulation currently allows only for 
simple projectile weapons (ie., the standard gun). 

The standard gun incorporates a barrel, wheels, motor, solenoid trigger, firing pin and 
magazine barrel. The gun is initially activated by turing on the motor that drives the wheels. 
These wheels spin at a high rate and will propel the projectile when pushed between them. The 
gun is gravity fed and uses a solenoid to push the firing pin forward, propelling the projectile 
forward through the spinning wheels. The wheel motion propels the projectile forward with 
sufficient velocity to easily fly the full length of the playing field (22 feet diaganal). 

Specific modelling of the standard gun used in SE 3015 has been deferred to later 
research. As with many aspects of the SE 3015, the students can tailor the performance of the 
standard gun to their requirements. The wheels that propel the projectile can be power by 6V 
DC to 10 VDC. The voltage used will determine the specific speed of the projectile. 

The standard guns can malfunction in several areas. The wheels which propel the 
projectile out of the weapon use O-rings. This O-rings can lift off of the wheels if the wheel 
speed exceeds its tolerance. This occurs when voltage above 10V DC are used. The gun is 
gravity feed from the magazine tube. The gun in the ready position will have round sitting in 
front of the trigger, and the solenoid firing pin assembly and behind the wheels, Figure 8.1. If 
the firing pin does not push the projectile into the wheels with enough force it will not catch on 
the wheels and remain in the chamber. This misfire will allow a second round to drop into the 
chamber and cause the projectiles to jam or to fall out since there will not be enough force to 


push two out of the chamber on the next trigger fire. 
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Figure 8.1 Standard gun side view block diagram 


B. ALTERNATIVE WEAPONS 

| Additional weapons systems used on the SE 3015 are only limited by the imagination of 
students, the weight and power supply, muzzle velocity and a few safety restrictions. A weapon 
must be safe enough for a person to take a hit. High speed projectiles, explosives, and NBC 


weapons (except Silly String) are not permitted. Weapons systems in the past have shot flying 
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discs, and pencils in addition to nets. Nets and Silly String hits are not scorable in the 


competition and are rather used to sabotage the functionality of the oppoenent. 


C. SIMBOT WEAPONS 

Despite the use of the standard gun there is not a full set of standard parameters for these 
guns. The standard gun’s muzzle velocity will vary depending on the amount of voltage used to 
drive the wheel motors. Itis possible, although difficult, for the student to calculate this velocity 
and enter it into the simulation, but this has not been done at this time. The velocity used in the 
simulation is calculated from the projectile motion and observed behavior of the standard gun 
projectile. 

The simulation uses only an estimated exit velocity for the standard gun. The gun muzzle 
is considered to be flush with the edge of the robot. The possibility of weapons malfunction 
from ammunition jamming or ring slippage is ignored. The solenoid firing pin is assumed to 
always hit the projectile with enough force each time to push the projectile through the wheel to 


launch the projectile. 


D. PROJECTILES 

The basic types of projectiles categories used in the SE 3015 course have included small 
spherical projectiles, odd-shaped projectiles, and soft objects. The spherical projectiles have 
included the wooden ball used in the standard gun, gum balls used in an air compression gun, 


and ping pong balls. The odd shape category includes a wide range of projectiles from pencils to 
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foam discs varying in density, size, and shape. The last category (soft objects) includes such 
things as nets, and silly string. 

For simplicity, only the standard projectiles will be incorporated into the simulation at 
this time. The simulation of other objects, although not impossible, requires a greater 
knowledge of their dynamics and interaction with the robot, as well as the behavior of their 
weapon system. The projectile used for the simulation is modelled from those used in the 
standard gun, a wooden ball with a maximum diameter of 0.516" (or 1.3 cm), with a density of 
450 kg/m’ (Kinsler, 1982, p.461) and a mass approximately 0.5 grams, assuming the projectile 
to be made of pine. Based on these figures, the projectile fired from approximately 1.5 feet off 
the ground will not reach terminal velocity, subsequently air drag is ignored. For the current 
simulation, the projectile motion has been simplified and ignores such things as the effects of air 


drag and the true initial velocity of the projectile. 


E. CALCULATING DEFAULT EXIT VELOCITY 

Due lack of standardization in the weapons system, it was decided to create a default 
velocity for the projectiles used. This default velocity was fixed by working the projectile 
problem backward using some assumptions of the robot construction, height of the gun, and the 
apsenetins that the projectile travels the length of playing field before impacting the ground. 

The gun fires horizontally from a height between 1 1/2 and 2 feet. Using the basic 
equations for projectile motion and considering the projectile to be a particle the total flight ime 
for projectile is dependent only on the launch height. Taking the height to be 1.5 feet, the flight 


time is calculated from Equation 8.1. 
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we ee = 0.215 (8.1) 
g 


The horizontal velocity of the projectile does not preclude the effects of air drag but it can be 
ignored for this approximate calculation for the standard projectile. The initial velocity of the 
projection has only a horizontal component. Using the assumption that the projectile will travel 
the length of the playing field 22 ft (6.7 m) before it reaches the ground the velocity is computed 


from the Equation 8.2, using t from Equation 8.1. 


range 
yi See 
t 


(8.2) 


This yields a minimum initial velocity for the projectile of 105 ft/s if the projectile is to reach the 
end of the playing field before hitting the ground. In reality the wooden ball projectile can easily 
exceed the 22 feet distance and therefore be travelling faster than 105 ft/s. However, until more 
measurements are conducted on the weapon systems used for the purposes of the simulation, this 
assumption should hold for most light-weight spherical objects used assumed velocity as 


projectiles in the SE 3015 Robot Wars competition. 


F. PROJECTILE MOTION 
The current simulation uses basic three dimensional projectile motion ignoring air drag, 
dispersion, and projectile shape. The projectile motion is broken into x and z components in the 


horizontal and the vertical y component. Although the y position is calculated, the projectile 
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used in the simulation have been set with a velocity which will preclude it from impacting the 
ground before leaving the playing field. 

The path of the projectile is calculated from Equations 8.3 through 8.5. where 9, is the 
gun angle of the Simbot at the time of fire and x and z are the coordinates of the Simbot center of 


mass. The height of fire is 1.5 ft or 150 grid units. Gravity is scaled to simulation space as 320 


grid units/ time unit? 


x,=vt cos, + xX, (8.3) 
a (8.4) 
Ze ii 3006 pan (8.5) 


Po 


For the standard gun projectile, the projectile height at impact will not be a consideration. With 
lower velocity projectiles, itis possible for the projectile to impact the robot at the same time as 
itimpacts the ground. At 105 ft/s, or 1050 grid units/tume step in simulation space, the projectile 
will be able to cross most of the playing field before the opponent moves hence the subsequent 


movement of the opponent will be ignored. 


G. SIMULATION PROJECTILE FLIGHT PATH 
| The simulation projectile’s flight path is calculated for each ttme step and compared to the 
position of the opponent. [If the projectiles flight path intersects with the body of the opponent 
before it reaches the ground it will constitute a hit. Otherwise it is considered a miss. 
Two matrices are used to simulated the projectile motion, the gun and bullet matrices 


described in Section 3.C and Tables 3.6 and 3.7. The gun matrix controls which weapon will be 
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fired. The current simulation can handle multiple simple projectile weapons through the gun 
matrix but is only set for one active weapon. 

The weapon is fired when the simCode calls the Simbot class outport function 
bot.outport(register, data_value) in its maincode. This function call can be used to access 
different types of I/O devices by indicating the register. Most of the weapons functions are 
handled through the outport function and POIDB I/O port. The data value sent indicates which 
weapon to fire. The Simbot class outport function is currently set up to handle only the PIODB 
register and one weapon. 

The robot class gunfire function will check the gun matrix for ammunition availability 
and if available will activate a bullet from the bullet matrix, assign an exit velocity, gun number 
and launch height to the bullet matrix elements from the gun matrix. The active bullet then 
receives the current x and z position of the robot, and its gun angle. 

The simulation fires the projectiles from the gun, activating the simulated bullets and 
tracks them through their active flight with the robot class projectile function. Bullets are 
considered active once they have been fired until they are deactivated by impacting the opponent, 
the floor or by leaving the playing field. Unfired bullets are by definition inactive. The bullet’s 
trajectory is tracked through the position function. Before the Simbot moves it checks the bullet 
matrix for active bullets. If an active bullet is found, the Simbot class function projectiles( ) 
will calculated its next position. 

In calculating the bullet’s trajectory, the projectile( ) function first determines the range 
between the current position of the projectile and the opponent and compares this to the length of 


the bullets projectile path travelled during the time step as determined by the velocity, or vt. If 


V2, 


the range, r, of the bullets current position to the opponent is less what the bullet would travel 
unimpeded during the time step, the function computes the bullets new position, using Equations 


8.6 through 8.8. 


aT cosU, + x, (8.6) 
ee st ty, CC (8.7) 
eet sinO, + a (8.8) 


The Simbot then checks the height of the bullet at this new position. If the height has 
fallen below 0, the bullet would have impacted the floor before it reached the opponent. At this 
point the bullet is deactivated and scored as a miss. If the bullet is still above O, then the Simbot 
calculates the distance between the bullets new position and the opponent body center. If this 
distance is less than the radius of the opponent, then bullet is scored a hit and is deactivated. If 
the distance is greater than the radius, the bullet is scored a miss and is deactivated, since it will 
travel past the opponent on the next time step. Figure 8.2 provides a diagram of a bullet fired 
from the Simbot that misses its opponent. _‘If the range to the opponent is greater than the 
distance the projectile would travel during the time step, the projectile function will use 
Equations 8.3 through 8.5 to update 7 position. As part of updating its position, the Simbot 
will check to make sure the bullet has not left the playing field. If the bullet has left the playing 
field, it will be scored as a miss and deactivated. The only bullets that will remain active after 
these calculations and comparisons are made are the ones that remain over the playing field, 


above O and have not yet reached the opponent. 


de 


distance 





Figure 8.2 Diagram of a fired bullet that misses its opponent. 0, is the firing angle. 


H. SCORING 

The robot which hits its opponent the most will win the Robot Wars Competition. The 
competition is scored by professors and/or students in the curriculum using visual and auditory 
cues to determine a hit. Due to the high velocity of some of the projectiles, the actual hit may 


not be observed. The scorer may use the sound of a hit or an observed ricochet off the robot to 
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verify a hit. Although this scoring method is fairly accurate, in the case of rapid-fire hits or 
background noise, it is possible for the scorer to miss a point. 

A projectile is scored as a hit if it impacts the opponent before it hits the ground. The 
Simbot is considered to be a solid object and an impact on any portion of the Simbot is scored as 
a hit. Once a projectile hits the floor, it is no longer in play. Therefore a ricochet off the floor 
will not count as a score. The momentum of the ricocheting projectile is not considered in the 
simulation. If the projectile impacts the ground at the same time it impacts the robot it will be 
considered a miss. In the case of the acutal robot, it 1s possible for a projectile to passes through 
an open part of the opponents structure without hitting the actual body, which would be scored as 


a miss. 


I. SUMMARY 

The simulation weapons systems based on simple projectile motion modelled from the 
standard weapon ammunition. The simulation will ignore the technical difficulties associated 
with the real gun such as a weapons jam will allow for this incorporation at a later date. Due to 
the number of unknown factors, the simulation of actual weapons used in the SE 3015 Robot 
Competition will be student dependent but a simple analysis of the projectile’s flight path and 
Benauior should allow students to tailor their simbot’s weapons to reflect their SE 3015 robot 


weapons. 
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IX. TARGETING AND TACTICS 


Target acquisition and a working weapons system are essential to the robots ability to 
fight. Effective targeting is dependent on both the optical systems and the student programmed 
robot code. The robot must be able to obtain a sense of how far away its opponent is and where 
it is relative to its own orientation in order to attack. Using a projectile type weapon with a 
limited magazine under the competition time constraints, the robot must be able to make each 


shot as accurate as possible. 


A. TARGET ACQUISITION 

The both the SE 3015 robot and the Simbot rely solely on its returned eye values to 
determine the relative location of its opponent on the playing field. The robot’s program helps it 
determine the speed and direction of its approach to the opponent. The left and right 


discrimination aids the robot in finding the bearing to opponent. 


1. Initial Acquisition and Search Routines 

At the start of the competition the SE 3015 robots are placed in opposite corners at one 
end of the playing field with a divider, see Figure 3.1, between them to initially block their 
peripheral view. The robots must move past this divider and make their initial target 
acquisition. This is easily done by simply instructing a robot to move forward past the divider 
and then begin looking while slowing spinning on axis until it acquires the opponent. Students 
in the past (with different initial conditions) have used other more complicated routines such as 


sprinting” to the far side of the playing field or developing an elaborate routine to determine 


on 


which side of the playing field that it is on, then moving forward and turn in the appropriate 
direction to acquire its opponent. 

After the robot has gotten past its initial acquisition phase, it will begin its targeting 
routine on its acquired target. Although, the robots can generally see the maximum diagonal 
length of the playing field ( approximately 22 feet) it can lose sight of its opponent. A routine to 
reacquire a lost target must be include in the robot’s code. This search routine can be as simple 
as Slowly spinning on axis until it reacquires the target. 

The Simbot will respond similarly to its SE 3015 counterpart, except the simulation 
playing field currently lacks the divider. Without this divider, the Simbot will be able to 
automatically see its opponent if the robot code instructs immediate search. This omission may 
cause the Simbot to behave differently than the SE 3015 robot on the actual playing field (see 
Section C) concerning obstacles. The simulation relies on the student having developed a robot 


code that has the robot move forward past the divider before it begins searching. 


2. Information Processing and Code Optimization 

As a general rule for the Robot Wars competition, the robot that can find and accurately 
shoot its opponent on a consistent basis will win the competition. In order to achieve this, the 
student needs to program the robot to quickly and accurately evaluate the signal levels of the 
robot eyes. Inherent to circuitry of the robots are the problems of background noise, interference 
and signal discrimination which may cause faulty eye readings that must be overcome ( see 
Chapter VI for more discussion on the optical system). The student is seeking to find the clearest 


signal, either from the circuits or from processing the signals from the eyes. 
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The robot code can be designed to obtain the cleanest signal levels from the eyes and 
filter out any anomalies caused by faulty readings using various algorithms before passing the 
information onto the rest of the code to evaluate for targeting. Previous strategies to eliminate 
the errors have ranged from ignoring them to elaborate schemes involving normalization and 
statistical averaging. Ignoring this problem can cost the robot time by acting on a faulty reading 
and possibly losing sight of the opponent robot. Computationally intense code that weeds out the 


error before the robot moves can cost time while the computer makes its decision. 


3. Decoy Lights and Background Lights 

The SE 3015 competition rules change from quarter to quarter, but in general decoy lights 
of one sort or another have been allowed. As a rule, the decoy lights are not at the same 
frequency or intensity of the robot beacon. Reflection of the light off the floors, walls, obstacles 
and the other robot can also cause faulty signal levels. 

Decoy lights can be deployed from the robot or remain attached to its body. A more 
intense signal at a frequency close to the beacon, at a harmonic frequency of the beacon, can 
saturate the opponents optics and make the robot think it is seeing the opponent at the wrong 
position. If the robot thinks its opponent is closer than what it really is, the robot may fire 
inaccurately, subsequently missing and using up limited ammunition. 

The simulation currently does not allow for additional light sources on the playing field 


nor does it incorporate the effects of background lights and reflectivity. 


79 


B. TACTICS 

In general, the robot will use the eye signal levels in a case statement to determine its next 
move. If the opponent is too far, the robot will move closer, if the opponent is on the left the 
robot will move to the left, and if the opponent is nowhere in sight, the robot will use a search 
routine until it detects it. A sample targeting flow is provided in Figure 9.1. Figure 9.2 shows 
how the routine would be written in Dynamic C for the robot and Figure 9.3 shows how this 
sample routine would be written in C++ for the Simbot. This basic decision tree allows the robot 


to find its opponent, narrow in on it, and then fire. 


. get signal levels for left and right eyes 
2. sum left and right eyes 


. 1f sum too small (i.e. not in firing range) 
move closer 
else if sum too large (i.e. saturation) 
move away 
else if left > nght 
move to right 


else if right > left 
move to left 

else if left = right and close to opponent 
fire weapon 

else (background level) 


. move robot accordingly 


.if time and ammo allow 
repeat steps 





Figure 9.1 Generic targeting flow. 
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The basic tactic shown in Figure 9.1 is slow and cumbersome. The robot will spin on its 
axis until the observed signal level is above background, if the difference between the left and 
right eye signal levels is great, it will continue spinning until the difference between levels is 
below an arbitrary set value. After the robot has decide that it is looking directly at its opponent, 
the robot will move forward to get within shooting range. As it is moving, if the difference in 
eye signal levels indicates that it is no longer pointed directly at the opponent, the robot will stop 
and begin turning until it is on target once again. Once the robot is close enough it will fire. An 
overhead view of the playing field would show the robot moving in a zig zag fashion. 

In order to defeat the opponent, the robot may have to use more complicated tactics to 
acquire the target and shoot. More elaborate targeting schemes breaks down the signal levels to 
reflect approximate distances from the opponent. At farther distances, the robot may move 
faster than at shorter distances. The student may incorporate curves and corner turns into the 
targeting routines to line the robot up for the shot. At the point of firing, students have used 
different tactics on how much to shoot when. 

The easiest tactic for attacking the opponent is to shoot all the rounds in the magazine 
once the robot is in range. The fault in this tactic 1s that once the robot is in firing range it is also 
generally in range to be fired upon by its opponent’s. Other tactics have included shooting a few 
rounds, moving out of range of the opponents weapon and then reacquiring the opponent, 
repeating this until it has no more ammunition. With larger magazines, the robots may not need 


to go to a defensive routine since the robot may be able to continuously shoot at its opponent for 
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the duration of the competition. For smaller magazines, the student may have to include 
defensive tactics to keep out of range of its opponent which may still have ammunition. 

The nature of the competition will dictate the need for tactics. With a small playing 
field and unlimited magazines for the weapons, it is possible for the competition be nothing more 
than a war of attrition. The robot with the larger magazine (and functioning weapon) will be the 
victor. If the playing field is large enough that the optical system cannot accurately track its 
Opponent across the playing field and the weapons range also cannot reach the limits of the field, 


tactics and target acquisition become more critical. 


C. DEPLOYED OBJECTS, OBSTACLES, MINES, AND DECOYS 

Previous SE 3015 Robot Wars Competitions have allowed obstacles on the playing field. 
These obstacles have include such things as wood blocks, decoy screens, and light decoys. The 
obstacles are generally deployed from a robot to impair the movement of its opponent (and 
sometimes itself). In order to simulate these objects, the simulation architecture will have to 
keep track of each of these items as it tracks the two Simbots. Incorporation of these obstacles 
will require adding a more detailed collision detection method in the simulation robot class and a 
greater knowledge of the obstacle itself. 

The easiest type of obstacle to incorporate into the simulation is a rigid body that does not 
move when a Simbot collides with it on the playing field. This type of obstacle has been used in 
the SE 3015 competition in the past in the form of a weighted mine placed on the playing field by 
the instructor. Obstacles that are placed on the playing field by deployment off a robot are of a 


much lighter weight and may or may not move when impacted by a robot. 
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In the March 1996 SE 3015 Robot Wars Competition, students deployed wooden blocks 
from their robot onto the playing field to impede the motion of the opponent. The blocks were 
wrapped in non skid material to keep them from sliding across the floor. The goal was for the SE 
3015 robot to run into the blocks and activate the bumper routine. In some cases this worked, in 
others, the block did not appear to even slow down the robot. 

Modeling the interaction between the robots and the obstacles in the simulation would 
require knowing the weight, dimensions, coefficient of friction and other such details explicitly 
for each of the obstacles. The playing field divider, also an obstacle, has not been incorporated 
into the simulation for this reason. The problem of simulating obstacles has been left for future 


research. 


D. SUMMARY 

The robot wars competitions vary from year to year in the use of weapons, presence of 
obstacle and size of the playing field, but the basic requirement to find and shoot the opponent 
remains. Quick and accurate target acquisition, a large magazine and a working weapon are the 
key components to victory. The simulation currently incorporates these basic principles and 


allows the student opportunity to test their target acquisition strategy on an open playing field. 
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X. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 

The simulation of the SE 3015 Robot Wars competition was created to extend the 
students’ understanding of weapon system design to the use of computer simulation and 
modeling. This simple model of the competition provides the ability to implement an 
individual’s robot code into a simulated environment. The simulation does not provide a true 
physical environment rather a synthetic environment in which to test robot design and code 
against an opponent. 

This simulation foundation of the Simbot and playing field environment is an ideal 
computer version of the SE 3015 Robot Wars Competition ignoring most of the real world 
performance parameters. The following are the capabilities included: integration of the Dynamic 
C robot code, left and right discrimination for targeting, optical sensor saturation limits, 
projectile velocity and basic robot motion. For a listing of the pertinent physical parameters and 
which one are included in the simulation, see Chapter IJ, Section B. 

The simulation is able to use the SE 3015 robot code for the Simbot without loss of 
original logic and tactics programmed by the user. The simulation does require, that the user 
provide some modification the function names and code lines for use in the simulation, but these 
have been kept to a minimum. The simulation contains the basic movement functions of the 
robots. It is able to interpret the motor control string commands accurately and move 
accordingly in the simulation environment graphical display. The optical portion of the 
simulation accurately handles left and right discrimination in the eyes to determine the relative 


angle of the opponent on the playing field. The simulation can respond to the signal levels 
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received and move according to the information as dictated by its code. Although the Simbot 
will respond correctly to the received signal levels, it lacks the ability to provide a true signal 
level for each eye commensurate with the relative distance of the opponent. The weapons 
portion uses a simple projectile motion to fire at the opponent when the simCode determines a 
targeting solution has been achieved. If the Simbot is close enough and at the correct angle of 
fire, the projectile will hit its target, else it will miss. The weapons lack the dispersion and errors 
found in the actual weapons. 

"Simulations are doomed to succeed,'' (often quoted, source unknown) and this one is 
no exception. The observer of the simulation sees reasonable looking play with no indication of 
whether or not it is realistic. Lacking the randomness of the physical world, simulation fails to 
illustrate the environmental conditions that have cost competitor’s their victory in the past. Dead 
batteries, fried circuit boards, jammed weapons, etc., have not been integrated into the 
simulation. The current simulation only employs the most basic of physics in order to get the 
simulation started but needs to incorporate a larger number of concepts. 

A test of the Dynamic C code in Appendix B was successfully integrated into the 
simulation as per the instructions in Appendix E. The Simbot, however, did not perform as 
expected. The simulation revealed a flaw in the original Dynamic C code that was not 
previously discovered. The code is missing a case for when only one eye detects the opponent 
and the other eye only detects the background signal level. During the Robot Wars competition, 
where the robot never lost sight of its opponent and the robot performed correctly. In the 
simulation the Simbot lost sight of its opponent in one eye and was not able to continue to 


function, requiring the simulation to be abnormally terminated. This incident illustrates the 
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potential value of the simulation to detect logic errors within the tactics since it can test for more 
cases. Appendix G, contains a video of the simulation demonstrations prepared to show the 


logic test capabilities. 


B. RECOMMENDATIONS FOR FUTURE WORK 

Future work should include a true optics simulation that incorporates the signal loss due 
to spreading and the efficiencies of the photo diodes and detectors. The robot base needs to 
incorporate calibrated angular velocities that correctly replicate the SE 3015 robot actions. The 
standard weapon needs to be extended beyond a simple projectile calculation to improve its 
functionality in the simulation. The Simbot needs to be able to handle multiple types of 
weapons. The interrupt functions need to be incorporated into the simulation of each of the 
Simbots vice the generic interrupt found in the Simbot class. 

The simulation needs to incorporate a Graphical User Interface (GUD) to allow the 
Simbots to be tailored to the specific robots modeled. Additional set functions need to be added 
to the Simbot class to fine tune the individual Simbots to their physical counterpart. A translator 
program which will take the Dynamic C code for transparent conversion of Dynamic C code into 
the simulation is needed. A better graphics display needs to be added, possible one to allow 


internet display of the competition. 


C. SUMMARY 
The simulation foundation incorporates a class structure to model the robot, C++ 


simulation code to allow the playing field interactions and graphics code to display the simulated 
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Robot Wars Competition. The fundamental physical movement of the robot has been correctly 
modeled and verified. The basic goal of the thesis has been accomplished. A simulation 
structure has been created that includes the basics of the Robot Wars and that provides 
visualization of the competition. The simulation has been designed so that the physical fidelity 


can be improved in a modular fashion. 
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APPENDIX A. ROBOT WARS COMPETITION RULES 


The most current rules for the SE 3015 Robot Wars Competition (Harkins, 1997) is 
provided. Whenever possible, the simulation should comply with the rules of the current course 
taught. The rules for the Robot Wars Competition are not static and can vary widely from one 
course to the next. The most rule changes involve the use of weapons and decoys. The course 
taught in Winter Quarter 1997, did not allow for decoys or included mines but allowed additional 
weapons. The course taught the previous year allowed for the mines and decoys but additional 


weapons, other than the standard gun were not permitted. 
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Harkins SE-3015, 8/96 


Robot Construction and Competition Rules 


Robot Requirements and Restrictions: 
1. Height and weight: 


Maximum weight limit: 35 Ib.. 
Maximum height limit: 4.0 ft. 


2. Beacon frequency assignments: 


These have been issued and are set by a trim pot on the beacon 
oscillator board. Each team has been assigned a unique frequency. 


The beacon will be mounted in a centered position underneath the top 
"deck" of the robot platform as discussed in class. Each beacon will 

give an unobstructed 360 degree view to the opponent (platform posts 
and the occasional wire is obviously accepted). 

3. Weapons: 

A standard weapon will be issued to each team. 

A secondary weapon system is encouraged but not required. 

The standard weapon is sufficient for final competition. The choice to 
not employ a secondary weapon system will not be held against the team 
for competition or grade purposes. 


3. Magazine limitations. 


The size of the standard gun magazine will remain as issued. 
Modifications to this magazine is not authorized. 


The size and scope of the secondary weapon system, if employed, will 
be limited by the height and weight limitations already listed for the 
platform. The magazine for the second weapon is limited to fifteen 
rounds. 
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4. Countermeasures: 


Countermeasures are authorized at the discretion of the instructor. If 
you have an idea check with me prior to use. 


5. Competition code: 


The robot program code will be fixed at the time of competition. This 
is to encourage pre competition testing. 


Code modifications between rounds will not be authorized. You will 
have to " Dance With The One You Brung". 


You will be allowed to reload if the system crashes. 
6. General competition rules: 


The final event for the course will be a round robin competition 
with the teams being seeded in the opening brackets in a random 
fashion. 


Each competition round will last three minutes. 


Your platform must demonstrate the classic "Detect to Engage” 
capability. This means you must have distinct and obvious search, 
detect and engage functions within your code. Shooting in the 
"shotgun" or "scatter" mode without regard to where your opponent is 
not allowed. 


A valid hit is when your weapon or projectile strikes your opponent. 
Strikes off of floor skips are valid as long as they are not a 

ricochet off of some other device, for example a chair, a leg or the 
mountain. Assigned judges will determine the number of hits per 
competition. The platform that inflicts the most valid hits on the 
opponent in three minutes will be declared the winner by the judges. 
The judges may walk on the playing field during the competition to 
ensure accurate counting. 


Your weapon may not inflict actual damage upon your opponents 


platform. I reserve the right to veto the employment of any device 
that is dangerous. 
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Ties, though not common, will be adjudicated by the flip of a coin. 
This is not very common but effective. 


On occasion there is a round of competition that simply needs to be 
restarted for some reason. I reserve the right to do this as required. 
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APPENDIX B. SAMPLE SE 3015 DYNAMIC C ROBOT CODE 


The Dynamic C code attached was provided by Wm B. McNeal and Jerry Sullivan and 
was used in the Winter Quarter 1997 Robot Wars Competition. The code is written with while 
loops and incorporates five functions: fire, search, and read in addition to the required functions: 
interrupt and platform. The fire function turns on the weapons and fires the rounds. The search 
function is used when the robot lost detection of the opponent and provides a serious of 
manuvers designs to locate the opponent. The read function obtains the eye signal levels from 


the A/D converter. 
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KKEKKEKKKEKEKKKEKKKKKEKKKEKEK KEKE KK KKK KEKE KK KKK KKK KKKEKKEKEKKKEKKKKKKKKKKEKK 


LT WM. B. McNEAL/LT JERRY SULLIVAN 
SE SUL5 
COMPUTER PROGRAM FOR ROBOT COMPETITION (ICEMAN) 


KKEKKKKKKKEKKEKEKEEKKEKEKEKEEKKEKEEKKKEKEKEKE KK KKK KKK KKK KK KKK KKEK KK KKK KKK EK 
BEREAN CREAR KR NR Neem RK WK ARI he ee re ee ee 


#use"serial.lib" 
#INT_VEC PIOA_VEC INT1 
char buf[9]; 

enhar Cc; 

iemitemnees ta CN teuSin. Shemite 
unsigned long int count; 
main () 

{ 

Ser “init zi10, 76007 L200); 
hv_enb() ; 

outport (PIOCA, Oxff); 
OUEpOoOrt(P1lOCA, OxXEL£); 
outport (PIOCA, PIOA_VEC) ; 
outport (PIOCA, 0x97) ; 
outport (PIOCA, Oxfc); 
outport (PIOCA, 0x87) ; 
OUEPOrE (PIOCB, Ox£f); 
outport (PIOCB, 0x00) ; 


ent=0; /*count for lost tracking if target is lost for approx. 10 secs search routine 
starts again*/ 


shent=0; /*this counter counts number of times eye detection criteria makes robot go 
straight 

as long as robot goes straight conter counts, if robot turns count goes to 
zero 

this ensures robot has truly acquired target before it shoots*/ 
read(); /* read for initial search routine */ 


for (count=0; count<50000;count++); /* this count is delay for search routine to let 
opponent get out first*/ 
search(); /* search routine */ 


while (1) { 

if (shent==17){/*if£ shoot count gets to 17 target has been successfully 
acquired* / 

fire(); 

fire(); 

fire(); 

shent=0; 

} 

read(); 
PP REI nee (9 \nCHO = sd Chl = 407 xy) 7 


/* THIS PORTION OF THE PROGRAM TAKES THE VALUES FOR THE LEFT AND RIGHT EYES COMPARES 
THEM AND EITHER 
TURNS LEFT, TURNS RIGHT OR GOES STRAIGHT */ 


/* SLOW SPIN SEARCH */ 
1f (x<=48 && y<=48) { 
strepy (buf, “4fgr4rgr"); 
platform (); 
cnt++; /* count for lost detection */ 
shent=0; 
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/*pmimiGe(*\ncount = %d@",¢ent) ;*/ 

if (cnt==500){ /* if lost detection count gets to 500 go back to search routine */ 
Crhte= 0; 
search ();} 


1f (x>48 && y>48) { 


/* FINAL DETECTION MODE stand off criteria*/ 
if ((x>=400 && y>=400) && (abs (x-y)<=50) ) { 
ecnt=0; 
shent++; 

SEreGrraput, sestorsr"); /* stand off */ 
platform(); 

for (count=0; count<1000; count++) ; 

Erre() ; 

fine): 


/* BOTH EYES EQUAL NOTE QUITE THERE */ 


if (((x<400 && x>=250) && (y<400 && y>=250)) && (abs (x-y)<=50)) { 
Gire—0; 

shent++; 

sercpy (buf, “aforafgr"); 

platform(); 


/* BOTH EYES EQUAL STILL APPROACHING */ 
1f (((x<250 && x>=100) && (y<250 && y>=100)) && (abs (x-y)<=50)) { 
ent=0; 
shent++; 
Stnepy (but, “cigrctgr" ) ; 
Dlattomm() ; 


7° BOTH EYEo, EQUAL INITIAL ACOUISITLIONs* / 
1f ((x<100 && y<100) && (abs (x-y)<=50)) { 
CHe—O; 
shent++; 
StLcpyaourt, "fforfftgr"); 
Dlacrorm(); 


/* SHARP LEFT TURN DIFFERENCE>2500 */ 
if (x-y>2500) { 
ent—0- 
shent=0; 
Strem our, "9fisrcfigr") ; 
platform(); . 
_ for (count=0; count<1000;count++) ; 


} 


/* SLOWER SHARP LEFT TURN DIFFERENCE>1000 BUT LESS THAN 2500 */ 
lf (x-y>1000 && x-y<=2500) { 
ecnt=0; 
shemt=0; 
strepy (buf, "9fsrefgr"); 
platform(); 
for (count=0; count<1000; count++) ; 


} 
/* SLOW LEFT TURN DIFFERENCE >500 BUT LESS THAN 1000*/ 


if (x-y>500 && x-y<=1000) { 
ent=0; 
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shent=0; 

strepy (buf, “argrafgr"); 
platéiomm() ; 

for (count=0; count<1000; count++) ; 


} 


/* LEFT TURN DIFFERENCE >50 BUT LESS THAN 500*/ 
if (x-y>50 && x-y<=500) { 
ent=0; 
shent=0; 
Strep (bur, "Srgorsgtor"); 
platform() ; 
for (count=0; count<1000;count++) ; 


} 


/* SHARP RIGHT TURN DIFFERENCE>2500 */ 
dE (y-x>Z500) { 


cnt=0; 

shent=0; 

SELCD, (but ws eeranoter §)-; 
platform(); 

for (count=0; count<1000;count++) ; 


} 


/* SLOWER SHARP RIGHT TURN DIFFERENCE>1000 BUT LESS THAN 2500*/ 
1£ (y-x>1000 && y-x<=2500) { 
ent=0 > 
shent=0; 
strepy (buf, “efgr9fsr*) ; 
Dlettormn() ; 
for (count=0; count<1000;count++) ; 


} 


/* SLOW RIGHT TURN DIFFERENCE>500 BUT LESS THAN 1000*/ 
if (y-x>500 && y-x<=1000) { 
enit—O ; 
shent=0; 
strepy (bwt, "afgrargr") ; 
platform (); 
£or (count=0; count<1000; count++) ; 


} 


/* RIGHT SEARCH TURN DIFFERENCE>250 BUT LESS THAN 500*/ 
1f (y-x>50 && y-x<=500) { 
Gne—U- 
shent—o- 
Strepyour, "Sftgréeror") ; 
platform() ; 
for (count=0; count<1000;count++) ; 
} 
} 


} 
interrupt reti INT1() /* INTERRUPT ROUTINE */ 
{ 
int data; 
unsigned long int counter; 
Bee 
data=inport(PIODA) ; 
if (data==253) 
{ 
strepy (buf, "ergrergr’); /* IF FWD INT IS TRIPPED GOES BACKWARDS *7 
platerorm( ) ; 
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for (counter=0; counter<7500;counter++) ; 

strepy(buf,"argrafgr"); /* AFTER BCKWRDS THEN SPINS TO FREE ITSELF */ 
plattomm() ; 

for (counter=0;counter<5000;counter++) ; 


} 
if (data==254) 
{ , 
strepy (buf, "cfgrefgr"); /* IF AFT INT IS TRIPPED GOES FORWARD */ 
Diletta ); 
for (counter=0; counter<7500;counter++) ; 
strepy (buf, “afgrargr"); /* AFTER FWD THEN SPINS TO FREE ITSELF */ 
platform(); 
for (counter=0; counter<5000;counter++) ; 
} 
return; 


} 


platform() 

{ 

Tea van 

CEe= sizeot(buf) ; 
outport (ENB485,1); 
ser_send_21 (buf, &cc) ; 
for (z=0;2<700;z++); 


} 


search() /* ICEMAN SEARCHES INITIALLY AND IF CONTACT IS LOST FOR MORE THAN 10 SECS */ 
{ 
unsigned long int counter; 
erm. 
1f (x<=48 && y<=48){ /*FIRST ICEMAN GOES STRAIGHT*/ 
Strepy (burt, *cfigrcfgr"); 
Dlatitorm() ; 
for (counter=0;counter <=8000;counter++) { 
read(); 
1f (x>48 && y>48) /* IF AT ANY TIME OPPONENT IS DETECTED PROGRAM GOES BACK TO 
MAIN SECTION* / 
return; } 


strepy (buf, "8fgr8rgr"); /*NEXT ICEMAN SPINS RIGHT*/ 
platform); 
for (counter=0;counter <=10000;counter++) { 
read(); 
1f (x>48 && y>48) 
return; } 
Strepy (bur, "“Sfgreftgr"); /*THEN ICEMAN SNAKES LEFT*/ 
platform(); 
for (counter=0;counter <= 5000;counter++) { 
. read(); 
if (x>48 && y>48) 
ete iiam: } 
Sepemy out, “CEgr5figr"); /* SNAKES RIGHT */ 
plattorm() ; 
for (counter=0;counter <=5000;counter++) { 
read(); 
if (x>48 && y>48) 
Eecurn - } 
Stnepy our, *sraretgr"); /* THEN ICEMAN SPINS LEFT -/ 
platform(); 
for (counter=0;counter <=10000; counter++) { 
read(); 
if (x>48 && y>48) 
return; } 


oy 


} 


return; 


} 


fire() /* ROUTINE TO FIRE GUNS*/ 
{unsigned long int counter; 
for (counter=0; counter<5000;counter++) ; 


outport (PIODB,0x40); /*CLOSES SOLENOID FOR DISK SHOOTER*/ 


for (i=0;1<10000; i++); 


outport (PIODB,0x88); /*STARTS BOTH GUN MOTORS* / 


for (i1=0;1<10000;1i++); 


eutport (PIODB,0x30); /*CLOSES SOLENOIDS FORK BOTH GUNS”/7 


for (i=0;1<2500; i++) ; 


outpoert (PIODB, 0x00); ©/*SHUTS OFF EVERYTHING*/ 


for (1=0;1<5000;i++); 


read() /*READS LEFT AND RIGHT EYE VALUES FOR COMPARISON IN MAIN SECTION* / 


{ 

x = ad_rdsg(0); 
y = ad_rd8(1); 
return; 


} 
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APPENDIX C. SIMBOT CLASS 

The Simbot Class code consists of a header file, SimbotClass.h and a class file, 
SimbotClass.C. As this class is only a foundation and will be rewritten to include more detailed 
models of robot components, the decision has been made to leave all class data members and 
functions are all public. 

The SimbotClass.h contains the list of parameters include and there variable names. 

The function prototypes are listed without description. The descriptions are found in the 
SimbotClass.C file. 

In SimbotClass.C, only two set functions have been developed, set to initially position 
the Simbot on the playing field, and set the magazine size, and setEyes to set the geometry of the 
optical circuit, saturation value and saturation minimum distance. Additional set function can 
be added to allow for setting more parameters of the Simbot and further differentiating the 
opponents from each other. Each function has a description preceding it. 

Two auxiliary functions, rad2deg, and deg2rad have been added to allow for easy 
conversion from radains to degrees and back. The C++ code uses radians for the trigonometric 


functions but the graphics package used requires degrees. 
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//FILENAME: SimbotClass.h 

//AURTHOR: Doreen M. Jones 

//DATE: 31 MAY 1997 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY: This is the header file for Simbot.h. The class does 

// not have any designated private data variables to facilitate future 
// development of the class but future research. 


#ifndef SimbotClass_h 
#define SimbotClass_h 


class SimbotClass { 
pubic: 


float 
float 
float 
float 
float 
float 


bullets[15] [8]; 
suns 3) lo; 
xpos; 

Zpos; 

theta; 

theta2; 


float oldang; 
int forward; 
int move; fe 
int bumper; VEE 
int bumper_count; 
int edge; Vo 
int edge_count; 
bane, clo Shonen 
float tick; 

int timer; 


// flag to indicate Simbot direction 
flag to indicate the Simbot is in motion 


flag for bumper hit 


flag for edge hit 


// speed factor, make sim run faster or slower 


char buf[8]; // motor control string from program 
int score; 
eel OOD; 


int edger; 
floaerrEloor; 


inte color, 
Inte rire: 
int shoot; 


float 
float 
float 
float 
float 
float 
float 
float 
float 


left; 

right; 

L_width, R_width; 
nose; 

max_level, background; 
MAX _EYE; 
Sat_dist; 
L_radius, 
separate; 


R_radius; 


SimbotClass(); 

void set(float xorigin, float zorigin, int mag, 
int paint, float time, float floorSize, 

void setEyes(float l_wide, float r_wide, float nozZe, 

float dist, float back); 

int ad_rd8(int nn, SimbotClass& Simbot) ; 

VOC Outport (int, Int); 

VOU Ory) : 


int moveable) ; 
float highest, 
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void initialize_gun(); 

void optics(SimbotClass& Simbot) ; 

void edge_detect(int &wl, int &w2); 

void bumpers (SimbotClass& bot2, int &wl, int &w2 ); 
void auto_ref(SimbotClass& bot2 ); 

void getVelocity(int &wl, int &w2); 
void platform(SimbotClass& bot2) ; 

void postemon(Gnt, int); 

void reposition(); 

youd Guni@re (); 

void projectiles(SimbotClass& botB) ; 
float relative_angle(SimbotClass& bot2); 
float range(SimbotClass& bot2); 


es 


#endif 


101 


//FILENAME: SimbotClass.cC 

//AURTHOR: Doreen M. Jones 

//DATE: 31 MAY 1997 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY: This file contains the class functions for the Simbot 
// class. Two auxillary functions are included to assist with the 
// degree to radian conversions. 


#include <iostream.h> 
#include <math.h> 
#include "SimbotClass.h" 


#include <string.h> 
#include <fstream.h> 
#include <stdlib.h> 
#include <iomanip.h> 


float deg2rad (float degree) ; 
float rad2deg (float radian) ; 


//fumeczoen. constuctor 

//description: creates the basic Simbot object with the Simbot placed at the 

// origin and the variables set to a neutral value. The position of the object 
// and other parameters are set in the set and setEyes functions. 


SimbotClass: :SimbotClass() 
{ 


xpos = 0; 

zpos = Q; 

eek = 1; 

timer = 0; 

theta = 0; // point the gun up the z-axis. 
forward = 1; 

move = -1; 

edge = QO; 

edge_count = 0; 


bumper = 0; 
bumper_count = 0; 


loop = OF 

edger = 0; 

shoot = 0; 
initialize_gun(); 
guns[0][0] = 14.0; 
ouns{lj][0] = 14; 
Gums lOvi2)] = 1050.0; 
qune tf lii[2)] = 1050.0; 
guns[0][1] = 14; 
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//function: set 

//description: similar to the constructor put is specifically for setting the 
// initial position of the Simbot, the weapon parameters and the color of the 
// simbot for use by the graphics program. 


void SimpocClass serttloat xorigin, float zorigin, int mag, int paint, 
float time, float floorSize, int moveable) 


{ 
xpos = Origin; 
Zpos = zZe@@agin; 
coer = paint; 
treke= time. - 
fliGer = floorSize; 
move = moveable; 
flee = 0; 
left = 0; 
iateict. — 0; 
guns[0][0] = mag; 
Gunsti)] [0] = 14; 
guns{0)[{2] = 1050.0; 
guns[1] [2] = 1050.0; 
guns(O} [1] = 14; 

} 

[ [err rrr rn = - 


// function: setEyes 

// description: this function will set the values for the eye geometry, the 
// maximum eye level, background and saturation distance. It uses the last 
// three to calculate the Kappa to determine the eye signal levels at the 
// ranges from the Simbot to its opponent. 


void SimbotClass::setEyes(float l_wide, float r_wide, float noze, float highest, 
float dist, float back) 


{ 
L_width = 1l_wide; 
R_width = r_wide; 
nose = noze; 
max_level = highest ; 
Satlaist = dist; 
background = back; 
MAX EYE = ((max_level - background) *sat_dist*sat_dist) ; 
} 
[| mn a reer cca 


// function: ad_rdsg 
// description: interface function used by the robot to obtain the eye signal 
// levels detected by the sensors. 


int SimbotClass::ad_rd8(int nn, SimbotClass &botB) 
{ 
Optacs (DOE) ; 
Pe eae = — let 
Peeurn right; 


} 
else { 

return left; 
} 
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// ,E£unees2on: optics 

// description: computes the eye signal levels for each of the eyes based on 

Th the range between the two Simbots, then if in the sights of the Simbot, the 
ee eye Signal values will be calculated using Formula 7.2, the levels for each 
Ta eye are determined by Formula 7.3 and 7.4 


void SimbotClass::optics(SimbotClass &botB) 
{ 

float dist = range(botB)/100.0; 

float ang = relative_angle(botB) ; 

float diff = theta - ang; 

float adiuce— tabs (aiff) ; 

float percent = 0 ; 

float eye, phi; 


int side; 
const int RIGHT = 0, LEFT = 1, BOTH = -1; 
if ((adif < 90) || (adif > 270)) { // in sites 
Po ciee = —sOMOMeditt == 260.0) { 
side = BOTH; 
} 
else if ((diff < 90.0 && diff > 0.0) || (diff < -270.0)) { 
Side = LEFT; 
i 
else if ((diff > -90.0 && diff < 0.0) || (diff > 270.0)){ 
Side = RIGHT; 
} 


} 


else { // it doesn’t see anything except background, so exit 
right i=slert = 16.0; 
return; 


} 


if (side == RIGHT) { // left side is obscured 
phi = rad2deg(atan(L_width/nose) ); 


} 

else if (side == LEFT) { //right side is obscured 
phi = rad2deg(atan(R_width/nose) ); 

} 


tee((adet < phi) {|| (adif > (36070-phi))) { 
if ade => 270.0) { 
percent = 1.0 - ((360.0 - adif)/phi); 
} 
else { 
percent = 1.0 - (adif/phi); 
} 
} 
else { 


pereent = 0.0; 
} 


Temtcrst. > Sat aust) { 

eye = (MAX_EYE)/(dist*dist) + background; 
} 
else { 

eye = max_level; 


) 


if (side == LEFT) { 


104 


right = eye; 
left = eye * percent; 
if (percent == 0.0) { 
left = background; 
i 
} 
else if (side == RIGHT) { 
right = eye * percent; 
left = eye; 
if (percent == 0.0) { 
right = background; 
} 
} 
else { 
letee— rront ="eve; 


// function: edge_detect 

// description: determines if the edge has been crossed by the Simbot and then 
// correct it so that the Simbot will not exit the playing field. If the edge 
v7 has been detected, the Simbot will act on the movement sequence in this 


// function before finishing the rest of its movement routine from the main 
i program. 
Lf mmm rr rrr 


void SimbotClass::edge_detect(int &wl, int &w2) 
‘ 
float edge_pt = 55; // this is the location of the edge detector from Simbot axis 
float xtemp = edge_pt*sin(theta2) ; 
float ztemp = edge_pt*cos(theta2); 
Elatameorx —forz, artx, artz; 


forx = xtemp + xpos; 
forz = ztemp + zpos; 
aftx = xpos - xtemp; 
aftz = zpos - ztemp; 


itmirabs i rorx) > £Lloor) { 
edge = 1; // forward edge 
edger++; 
edge_count = 40; 


Piemicabosi(torz) > Lloor) { 
edge = 1; // forward edge 
edger++; 
edge_count = 40; 


MemCnraisstartez) > floor) { 
edge = 2; // back edge 
edger++; 
edge_count = 40; 


Pemtctaesi(attz) > Eloor) { 
edge = 2; // back edge 
edger++; 
edge_count = 40; 


if (edge_count <= 0) { 
edge = 0; // no edge detected. 
reposition(); 
edger = 0; 


105 


} 
else { // finish existing edge detection routine 
if (edge == 1) { 
if (edge_count > 30) { 
wl = -14; w2 = -15; 
} 
else { 
Wie OW 2 ee 
} 


} 
else if (edge == 2) { 
wl = 15; w2 = 14; 
} 
else { 
return; // escape there should be any other values but 1 or 2 
} 


edge_count--; 


// function: bumpers 

// description: this checks to see if the Simbot has bumped into anything and 
// then responds appropriately if it has. This reaction takes precedence over 
// the movement and over the edge detection. This program checks for multiple 
// occurance of the routine that have failed to finish. 


void SimbotClass: :bumpers(SimbotClass& bot2, int &wl, int &w2) 
{ 

float radiusx2 = 120-0; 

float temp = range(botz2); 


3f  (eemps<= radiusx2) { 
ifecconwatrae—— 1) { 
bumper = 1; 


loopt++; 
} 
else { 
bumper = 2; 
loop++; 
} 
if ((bot2.theta > (theta+90.0)) && (bot2.theta > (theta-90.0))) { 
bot2.bumper = 2; 
Loop++; } 
else { 
bot2.bumper = 1; 
loop++; } 


bot2.bumper_count = 40; 
bumper_count = 40; 
} 


else if (bumper_count == Q) { 
bumper = 0; 
reposition (); 
loop = 0; 
} 
if (bumper == 1 && bumper_count > 0) { 
wile = wW2 = —is, 


bumper_count-~--; 
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else if (bumper == 2 && bumper_count > 0) { 
Wiee= We = 15> 
bumper_count--; 


} 
auto_ref (bot2) ; 
return; 
} 
aan aaa ea ce + ee | | ee 


/7 tunceion: auto ref 

// description: this function attempts to correct for the cases where there are 
// multiple unfinished edge or bumper routines. The function corrects by trying 
// to rotate the robots or move them aside to get them out of the problem. 


void SimbotClass::auto_ref(SimbotClass& bot2) 


{ 
if (loop > 5 && edger > 5) { 
xpos += 50; 
zpos += 50; 
bot2.xpos += 50; 
bot2.zpos += 50; 
loop = edger = 0; 
} 
else WE (loop > 5)e¢ 
theta += 45.0; 
bot2.theta += 45.0; 
loop = 0; 
} 
return; 
} 
i i a a a ee eee eee 


7/7 conction. position 
// description: calculates the next position and rotation of the Simbot on 
// the playing field. 


void SimbotClass::position(int wl, int w2) 
{ 


Gometerloat r = .25, ad = 1.0; 
float thetal; 

Plodtavs = wl * x; 

flcat v2 = w2 i 


* 


@neeal = 9 (2.0* (vl-v2) / d) * tick; 
theta += thetal;: 


// calculate the total velocity 
fle@atweiaest = (vl + v2) / 2; 
// determine what direction 
TemGrrrst >= 0) £ 

EGrwana = 1; 
} 
else { 

forward = 0; 


} 


theta2 = deg2rad(theta) ; 
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first*sin(theta2) *tick; 
first*cos (theta2) *tick; 


fioat tx 
fleat tz 


a 


if (theta > 360 || theta < -360) { 
int temp = theta/360; 
theta = theta - float (temp*360); 
} 
if (theta < 0){ 
theta += 360; 
} 


if (theta == || theta == 180) { 
tx = 0; 

} 

else if (theta == 90 || theta == 270) { 
EZ =O; 

3 

xpos xAUOS + EX; 


Zpos ZpOSs + tZ; 


// function: reposition 

// description: This function will check to make sure that the Simbot has not 
// moved off the playing field and return it to a point near where it left, if 
// it has left. 


void SimbotClass: :reposition() 


{ 
if (xpos < -floor) { 


xpos = - 650; 

} 

else if (xpos > floor) { 
xpos = 650, 

} 

else if (zpos < -floor) { 
zpos = -650; 

} 

else if (zpos > floor) { 
zpos = 650; 

} 

return: 


// function: getVelocity 

// description: this function breaks down the motor control string into the 

yy appropriate angular velocities for the wheels. This function assumes that 
// valid motor control strings have been entered. 


void SimbotClass::getVelocity(int &wl, int &w2) 
{ 

burt lo]: 

bot |4 |. 


wl 
w2 


LEMwheS 96) { 
wl -= 87; 
} 


else { 
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wl -= 48; 


} 

Tee Sueieie—— co) { 
wl = -wl; 

} 

Peto = 9S’) { 
Willis 

} 


Viesviec—do|| wl > 15) { 
Couten= tl! ERROR !'!titt* << endl; 
Coutc <- sputter strings’ << buf << “is wrong" << endl; 


} 
tf (w2M> 96) { 
w2 -= 87; 
} 
else { 
w2 -= 48; 
} 
Pee ( burs) ¢== 9 r*) 
w2 = -w2; 
Mem oue ole=— Ss) 
w2 = 0; 
Pimiwee =—15 si W2 > 15) { 
Gouc  <<cme UTI) ERROR !'!)!)11% << endl; 
COubrec-) "Durter String “ << buf <<,."4s wrong” << endl; 
} 
return; 
} 
 imaitinnnaaacce cco! CS eee Bee OSS ee ee eee ae eee ee 


P 7  eeunceron- platform 

// description: This function will move the Simbot, and the projectiles by 

// calling the appropriate functions. The order of sequence is to move the 

// projectiles, check the bumper, check the edge and then if both or okay then 
// move the Simbot. 


void SimbotClass::platform(SimbotClass& bot2) 
{ 


Tht wl, we: 


projectiles (bot2); 
bumpers (bot2, wl, w2); 


PEotbumper == ©) -{ 
edge_detect (wl, w2); 
if (edge == 0) 
getVelocity(wl, w2); 
else 
Count—-—; 


} 


position(wl, w2); 
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//TEUAGETOn: initeval zesqun 
// description: this function initialized the matrix used for the bullets 


void SimbotClass::initialize_gun() { 


fOmmmincet i= O; 137 < 15; Li++) ¢ 
for ( int jj= 0; jj < 8; jj+t) { 
bubletrs (ii) [397] = O20; 
} 


// function: gunfire 
// description: this function obtains the starting position of each of the 
// projectiles at the time from the Simbot’s position and gun angle 


void SimbotClass::gunfire() 
{ 
if (guns (Ojefl)] >= 0) { 
shoot = 1; // sets a color flag for the graphics 
int mag; 
mag = guns[0][0]; 
Int) round; 
Found = guns (0) [1]; 
guns[0][1] -= 1.0; 
bullets [round] [0] 
bullets [round] [1] 


1; // make the bullet active 
theta2; // firing angle 


bullets [round] [2] xpos; 
bullets [round] [3] 150.0;// gun height 
bullets [round] [4] ZpOS; 


bullets [round] [5] guns[0)[2]; // projectile velocity 


} 
else { 
shooc.= 20; 
} 
} 
Df re rr er ee eccce-- 


// function: projectiles 

// description: this function at each time step will check the bullet matrix 
// for active bullets and move them if appropriate. This function will check 
// to see if the bullet has hit the other Simbot or missed. 


void SimbotClass::projectiles(SimbotClass& botB) 
{ 


int mag; 
mag = guns[0] [0]; 


for (imeeaa = mag ; ii >= 0; ii--) { 


tf (bullets[iij](0] == 1) { 
#2 ((range (botB)) < (bullets[{ii] [5])/*tick)) { 
float secs = ((range(botB)) / (bullets[ii] [5] *tick)); 


bullets[ii] [2] += sin(bullets [ii] [1])*bullets[ii]) [5]*secs; 
bullets[ii][3] += -0.5*980.0*secs*secs; 
bullets[ii][(4] += cos(bullets[ii][(1])*bullets[ii]) [5]*secs; 
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1f£ ((bulletsieiaiis)) <= 000)>% 
cout << "missed" << endl; 
bullets[ii] [0] = 3; 
} 
float bull = sqrt(((bullets[ii] [2]-botB.xpos) * 
(bullets [ii] [2] -botB.xpos) ) 
+ ((bullets [ii] [4] -botB.zpos) * 
(bullets[ii] [4] -botB.zpos))) ; 
Tt wieurl <= 700.0) { 
Gout a-<eo hie eSimbot“*»<< ena 
butiecs [iri (O] = 2; 


} 
else { 
cout << "missed" << endl; 
builets[i1i)] [0] = 3; 
} 
} 
else { 
bullets[iiJ][(2] += sin(bullets [ii] [1]) *bullets[ii] [5] *tick; 
bullets[ii] [3] += -980.0*tick; 
bullets[iiJ][4] += cos(bullets[ii] [1]) *bullets [ii] [5] *tick; 
i ((bullers{i1i) (3) ) <= 0.0) ¢ 
cout << "hit the ground" << endl; 
bullets[iiJ[0] = 3; 
} 
if ((fabs (bullets[ii][2])) > fleor) { 
cout << "missed" << endl; 
piperets (ii) (O]) = 3; 
} 
af ((fabs (bullets[ii][4])) > £loor) { 
cout << "missed" << endl; 
bullets[({iijJ[0) = 3; 
i 
} 
} 
} 
} 
[fl mmm rn = 


/7 Stuneteon: print 
// description: used to dump the parameters on to the screen if desired. 


void SimbotClass: :print() 


{ 
cout << "“----- Simbot statistics ----- " << endl 
<< "xpos = " << xpos << " zpos = " << zpos << endl 
<< "theta = " << theta << " buf = " << buf << endl 
<< " move = " << move << " count = " << timer << endl 
<< "“bumber = " << bumper << " count = " << bumper_count << endl 
<< "edge = " << edge << " count = " << edge_count << endl; 
} 
ee (a ae te a 


// stuneteron:  Ooutport 
// description: this function is an interface function between the simCode and the 
// class to fire a projectile. Calls the gunfire function. 


void SimbotClass::outport(int port_type, int port_nwum) 
{ 
PEN (Done stype == 2) { 
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ihe (POreenum == 2) 4 
gunfire() ; 


// function: range 
// description: calculates the distance between the two Simbots. 


float SimbotClass::range(SimbotClass& botB) 
{ 
float range; 
range = ((botB.xpos-xpos) * (botB.xpos-xpos) ) 
+ {((5etS.zpos—-Zpos) ™ (botB-zpos-—zpoes))}; 
return (sqrt (range) ); 


// function: relative_angle 
// description: translates the Simbot to the origin and then calculates the relative 
// angle from itself to the other Simbot. 


| | a a a a ne = 9 = = = 
float SimbotClass::relative_angle(SimbotClass& botB) 
{ 

float xbot = botB.xpos - xpos; 

float zbot = botB.zpos - zpos; 

float ang = atan2(xbot, zbot); 

ang = (rad2deg(ang)); 

if (ang < 0) { 

ang += 360.0; 

} 

return ang; 
} 
bf a i a nn ee 
// These are two auxillary functions designed to convert between radians and 
// degrees. C++ uses radians for the trigonometric functions but the graphics 


// package uses degrees. Most of the comparisons of gun angles use degrees 
// which the author feels is easier to visualize. 


float deg2rad (float degree) 
{ 

return (degree/180.0) *3.1415; 
} 


float rad2deg (float radian) 


{ 
return (radaan/3.1415)*130.0; 
} 
Lf mre 
// end of SimbotClass.c file. 
Tf rer erene 


eZ 


APPENDIX D. SIMULATION CODE 


The simulation main program is contained in the dual.C program that follows. The 
program has been provided without simulation code in place of the SimCode (also known as the 
process function) The SimCode is to placed in the process function, as discussed in Appendix E. 
The process function contains dummy code to allow the program to be compiled and even run, 
although the robots will not move. This code is not robust and does not allow the user to directly 
input any data except the end time of the simulation. To make changes to the Simbot objects the 


user must hard code the set and setEyes functions. 
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// Euncbicn sadual .c 

// author: Doreen M. Jones 

// date: May 31, 1997 

// compiler: SUN/UNIX on SGI 

// summary: this is the main driver function for the simulation requires 
// two robot codes to properly run (not included here) This simulation 
// sends the data from the Simbot movements to individual data files 

// the simulation will dump the projectile information onto the screen 
// but does not send this to the data files. Uses UNIX system commands 
// to facilitate the switching from one Simbot to the other. 


#include <sys/types.h> 
#include <unistd.h> 
#include <iostream.h> 
#include <sys/prctl.h> 
#include <sys/wait.h> 
#include <signal.h> 
#include <sys/param.h> 
#include <iomanip.h> 
#include <string.h> 
#include <fstream.h> 
#include <math.h> 
#include "SimbotClass.h" 


VO2d processes (void *); 
void platformA(); 
void position2 (); 


SimbotClass botaA; 
SimbotClass c3p0; 
Int flag = 1; 


int PIODA 
int PIODB 


Le 
Ze 


int producer_pid; 
int consumerA_pid; 
int consumerB_pid; 


G; 
oO; 


int master_timerA 
int master_timerB 
int temp = 0; 
ofstream outBot("BotAscript.dat", 10S::out); 
ofstream outBot2("BotBscript.dat", i10S::out); 


int main() 

{ 
inte dime; 
cout << "enter end limit" << endl; 
Gin >> Jamie: 


// botA is the grey simbot 

botA.set(-600.0, -600.0, 15, 4, 90.0, 800.0, 0); 
C300 seeupu0.0,9-000.0, 15549, 90.0, 800.0, —1); 
Stecey (BbotAcbuf, “Otgrdtgr"): 

Stpcoy (C35pU0.bUuL, “EEGrrraqr) ; 


1670): 


botA.setEyes (1.0, Sen O40. Oy 
0, 1620); 


TC; oe 
e3p0 seteves (150, 1.0, 1.5, 2040. or 


‘ 
‘ 


Oo 


void processA(void *); 
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Peeaducerspia = getpiid()>; 
consumerA_pid = sproc(processA, PR_SALL) ; 
consumerB_pid = sproc(processB, PR_SALL); 


setblockprocent (consumerA_pid, 0) ; 
setblockproccnt (consumerB_pid,0); 
setblockproccnt (producer_pid, 0); 


fliag = 1; 
unblockproc(consumerA_pid) ; 


while(temp < limit) { 
while (flag) { 
blockproc(producer_pid) ; 
} 


flag = 1; 
unblockproc (consumerB_pid) ; 


while (flag) { 

blockproc (producer_pid) ; 
} 
flag es 1; 


unblockproc (consumerA_pid) ; 
temp++; 


} 


cout<< "end game "<< endl; 
cout << "botA stats = " << endl; 
POree( tei = Aeee sy) Sa 0; 1i——) <{ 
fon “amegj7 — 0; 353 < 8s Girt) { 
cout << DotA bullets[iijJ[jj] << ‘ * ; 
} 
cout << endl; 
} 
Soulia<) Dots stats = " << endl: 
EOmeeire=l4- 99 >= 0; ai=-=) { 
Pemeantee jje=)0; J) < 8; j++) { 
Souc << ¢3p0.bullets(iij([jj] << * ’ ; 
} 
cout << endl; 
} 
kill (consumerB_pid, SIGKILL) ; 
kill (consumerA_pid, SIGKILL) ; 
return 0; 


// function: processA 

// description: this is where the simCode for Simbot A will be placed. 

// this function holds the simCode and steps through it in a similar manner 
// as the robot does. 


void processA(void *) 
{ 
platformA() ; 
return; 


iS 


// description: platformA 

// description: acts like the Dynamic C platform function in that it will send 
// the information to the motor controller but it also sends the data to the 
// output file and sets the flags to hand off to control to the other Simbot. 


void platformA() 
{ 
while (!flag) { 
blockproc (consumerA_pid) ; 


} 


ofstream outBot("BotAscript.dat", ios::app); 
outBot << setiosflags(ios::fixed) << setprecision(2) ; 
outBot << setw(6) << master_timerA++ << ’ ' 
<< setw(6) << (botA.theta-90) << ’ ' 
<< setw(2) << botA.color << ’ ’ 
<< setw(7/) << botA.xpos << ’ ’ << botA.zpos << ’ ' 
<< endl; 


DOEeAeplertrorm(c3poO) ; 


flag: — 10! 
unblockproc(producer_pid) ; 


// function: processB 

// description: this is where the simCode for Simbot B will be placed. 

// this function holds the simCode and steps through it in a similar manner 
// as the robot does. 


void processB(void *) 
{ 
poOSTeron2 ().; 
return; 


// description: position2 

// description: acts like the Dynamic C platform function in that it will send 
// the information to the motor controller but it also sends the data to the 
// output file and sets the flags to hand off to control to the other Simbot. 


void position2() 


{ 


while (!flag) { 
blockproc (consumerB_pid) ; 


} 
ofstream outBotB("BotBscript.dat", i1os::app); 


outBot2 << setiosflags(ios::fixed) << setprecision(2) ; 
outBot2 << setw(6) << master_timerBt++ << ’ ' 
<< setw(6) << (c3p0.theta-90) «<< ’ ’ 
<< setw(Z) << c3p0.ccolor << ’ ' 
<<"setmwns) << C3p0.xpos << ° ' << C3p0. zpos << ° 
<< endl; 
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e300 platform( bots 
fag = 0. 


unblockproc (consumerA_pid) ; 
unblockproc (producer_pid); 


te 





APPENDIX E. DYNAMIC C CONVERSION 


The following is required for the initial setup before the conversion can be accomplished. 


i) 


11) 
111) 


iv) 


v) 


V1) 


vli) 


V1i1) 


1X) 


At least one working Dynamic C program (1.e., compiles and mins the robot), two 
working programs are better. 


The Dynamic C program must be written with while loops. 
Identify which robot is botA and which is botB. 


Determine how many PIODA and PIODB CALLS are made and what they do. 
The simulation in its present state only allows for a fire signal identified as 0x02. 


Check the for loops, they need to be incrementing and use the same counter for 
the ones that control the amount of time the robot will move for. 


The simulation only allows for one set of eyes. In the ad_rd8(int n) function, 
n=0 is the left eye and n=1 is the right eye. 


Identify the #define statements used and determine their importance. In the 
present simulation, #define statements can work, but you have to make sure they 
do not conflict with any others in the main program and in other robot code. 


Create function prototypes for any additional functions used in the code (besides 
the platform and interrupt functions). The function prototypes need to be 
inserted before the related process function. 


All comment lines need to start with // instead of the C style block commands /* 
or just remove all comments. 


The following steps will guide you through the robot code conversion process. 


F: 


2 


The first program to be converted is botA. 


Using the text editor search and replace command, change the following function 
calls to reflect the Simbot class requirements. 


Change platform to platformA. 

Change outport to botA.outport. 

Change the counter variable name to botA.count. 
Change buf to bot.buf. 

Change ad_rd8(0) to botA.ad_rd8(0, botB). 


2 Se oe 
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f. Change ad_rd8(1) to botA.ad_rd8(1, botB). 


2, Place any #define statements used at the top of the program. (Note: if the 
program does not compile because of this, consider eliminating them altogether.) 


4. Remove any hardware setup code lines. 

3. Remove any #use or #include lines. 

6. Remove the platform and interrupt functions. 

de Create the function prototypes and place them before main. 

8, Remove any extraneous code lines above main (i.e., hardware setup lines). 

a Exchange the for loop and platformA lines and remove the semicolon after the 


for loop line (see Figure 5.1). 
10. Rename main( ) as processA(void *). 
11. Save to a separate file. 


12.‘ Find the processA/SimCodeA place holder in dual.C. Highlight the place holder 
and copy/insert the file created in step 11 over the place holder. 


13. Repeat the steps above for the other robot, substituting B for A. 


Not all situation have been incorporated into the current simulation. The robot code may have 
functionality that has not been incorporated into the simulation. For instance, gun motors are 
considered to be on at all times. The converted code that follows was created from the Dynamic 


C code found in Appendix B. 


120 


APPENDIX F. USING THE SIMULATION 

Once the robot code has been converted to Simcode and assimilated into dual.C, the 
programs must be compiled. At the command prompt, type make dual. If the program fails to 
compile it may mean one of several things. The most prevalent errors will be from failure to 
remove all C style comments. After debugging, and remaking, type dual at the command 
prompt. Run the simulation for the desired length of time, 2000-5000 provide several minutes 
of simulation. Values less than 500 are not very beneficial. Dual is complete, type 
show_wars at the command prompt. Enter the desired start and stop times after the prompts. 
The simulation graphics windows will open on the screen. Additional functionality is found in 
the second window. The graphics portions 1s designed with 6 different view angles and replay 
ability. The program will create two output data files: botAscript.dat and botBscript.dat. The 
files contain the time count, rotation angle, x-position and Z-position. 

To run the graphical program, type show_war at the prompt. The program will be 
expecting to find the two files listed above and will not run if the programs are not available to it 
in the same directory. Then type in the start and stop times to view. This code is not robust, but 
it will not proceed if you did not type in a stop time that is higher than the start time. Once the 
animation has started you can use the camera buttons to change the viewing angle. The pause 
button will stop the animation at that frame until you hit the move button. The replay button 
will reshow the portion of the animation previously shown and the restart button will request 
new Start and stop times in the command window. The floor options changes the type of 
flooring to slow down the display. Currently there are only two type of floors, the fast and the 


slow. The neutral option will display the fast floor. The end button will exit the program. 


vA 





APPENDIX G. SIMULATION ANIMATION CODE 


The simulation animation or graphics package is contained in ten files. The animation 
program uses the data files, Botiscript.dat and Bot2script.dat created by the dual.C program. 


A brief description of the graphics files is include below. 


1. show_war_funcs.h - header file for show_wars.C containing the function prototypes 
2. show_war.C - main animation file that controls the animation of the Simbot Wars 


3. materialsupport_funcs.h - contains the function prototypes for the material colors 
used in the 


4. materialsupport.h - contains the variables assigning color names to integer for use in 
the draw support functions 


5. materialsupport.C - contains the functions to create the colors used in the animation 


6. drawsupport_funcs.h - contains the function prototypes for drawsupport.C and the 
prototypes for drawBot.C. 


7. drawsupport.C - contains the OpenGL primitives to create the playing field and the 
Simbots in the animation 


8. drawBot.C - contains the 3-D Simbot model created from OpenGL primitives for use 
in show_wars.C. 
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//FILENAME: show_war.h 

//AURTHOR: Doreen M. Jones (derived from M. Zyda class notes. 
//DATE: 31 MAY 1997 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY: This is the header file for show_war.C 


static void initCB (Widget w, XtPointer, XtPointer call_data) ; 
static void exposeCB(Widget w, XtPointer, XtPointer ); 

static void resizeCB (Widget w, XtPointer, XtPointer call_data ); 
Static void inputCB(Widget, XtPointer, XtPointer call_data ); 


static void quitCB(Widget w, XtPointer, XtPointer) ; 
static void resetCB(Widget, XtPointer, XtPointer) ; 


static void ReplayCB(Widget w, XtPointer, XtPointer); 
Static void Types_of_lightsCB(Widget w, XtPointer, XtPointer) ; 
static void movementCB(Widget w, XtPointer, XtPointer) ; 


static void cameralCB(Widget, XtPointer, XtPointer); 
static void camera2CB(Widget, XtPointer, XtPointer); 
static void camera3CB(Widget, XtPointer, XtPointer) ; 
static void camera4CB(Widget, XtPointer, XtPointer); 
static void cameraSCB(Widget, XtPointer, XtPointer) ; 
static void camera6CB(Widget, XtPointer, XtPointer) ; 


GLboolean drawWP(); 

void draw_the_scene(); 

void make_the_window_for_the_controls(); 
void create_toggle_widget (Widget parent); 


void create_nine_entry_selector ( 


Widget rc, // Parent widget is a RowColumn container. 

char *radioboxname, // Text name to use for the RadioBox. 

char *all_labels[], // All the labels for the selector. 

XtCallbackProc all_callbacks[], // All the callbacks for each 
//7ORELOn® 

XtPointer all_data[], // Pointers to the data to be passed 


// to the callbacks. 
Widget all_toggles[]); // Returned toggle widgets. 


void initialize _toggle_states(); 
void build_accumulative_matrices(); 
void reset_show(); 


static void slow_floorCB(Widget, XtPointer user_data, XtPointer) ; 


static void neutralCB(Widget, XtPointer user_data, XtPointer); 
Static void fast_floorCB(Widget, XtPointer user_data, XtPointer); 
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//FILENAME : 
//AUTHOR: Doreen M Jones 


show_war.C 


] ORI MAY 1997 


//COMPILER: SUN/UNIX on SGI 


(derived from M. Zyda class notes 


//SUMMARY: This is the main driver program for the simulation 


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#include 
#include 
#include 
#include 


graphics display. 


a more detailed scene. 


<Xm/Xm.h> 
<Xm/Form.h> 
<Xm/Frame.h> 
<Xm/RowColumn.h> 
<Xm/CascadeB.h> 
<Xm/PushB. h> 
<Xm/ToggleB.h> 
<Xm/Separator.h> 
<GL/GLwMDrawA.h> 
<X11/StringDefs.h> 
<X11/keysym.h> 
<GL/gl.h> 
<GL/glu.h> 
<GL/glx.h> 
<iostream.h> 
<math.h> 
<stdlib.h> 
<fstream.h> 


"show_war_funcs.h" 


"materialsupport.h" 


Get 


Get 
Get 
Get 
Get 
Get 


It requires the direct use of the drawbot.c 
and drawsupport.C files to create the objects in the scene. 
this was designed to maximize the animation speed vice the 
As this is a derived program, 
latent functionality remains that is not used by the program. 


some 


the Motif stuff... 


We are going to use a Form container widget. 


the 
the 
the 
the 
the 


Frame widget. 
RowColumn widget. 
CascadeButton widget. 
PushButton widget. 
ToggleButton widget. 


// Get the Separator widget. 
// We are going to use an OpenGL Motif Draw widget 


// Get 


"materialsupport_funcs.h" 
"drawsupport_funcs.h" 


static XtAppContext app_context; 


static XtWorkProcId workprocid = NULL; 


Static GLXContext glx_context; 


Display * 


global_display; 


Window global_window; 


XmStringCharSet charset = 


static float dummy; 


the OpenGL required includes. 


// C++ I/O subsystem. 


// Get exit() function. 


// Get this program’s function declarations. 
// Get material names. 
// Get the material support functions. 
// Get the drawing functions. 


Applications context. 

Id of the work procedure 
A GL context (see initCB). 
Global display. 

Global window. 


(XmStringCharSet) XmSTRING_DEFAULT_CHARSET; 


// dummy variable for widgets 


extern float FloorSize = 1500.00; // default value 
void All_lights_on() ; 

// camera values 

Static £Eloat frogl = 2000; 
static float fErog2 = FloorSize; 
Static tloat frog3 = -511; 
Static float toadl = 0.0; 
Static float toad2 = 0.0; 
Static float toad3 = -511.0; 
GLboolean lightType = FALSE; 
GLboolean slow_floor = FALSE; 
GLboolean fast_floor = FALSE; 
GLboolean StartUp = FALSE; 


static int floorStyle 


static int eyepoint = 0; 
static int start_time = 
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static int end_time; 
static int reset = 
static int pause = 0; 
Arg wargs[15]; // Args used with XtSetArg below. 
inten; // Used to specify number of args. 


//function: main 
//description: starts up the GUI and begins drawing the scene 
// which continues until told to stop. 


9 SS SS SS SS SS S55 
void main(int argc, char **argv) 
{ 
Arg wargs([(15]; // Args used with XtSetArg below. 
chook eer // Used to specify number of args. 
Widget toplevel; // The top level (shell) widget. 
Widget form; // The topmost container widget (excluding the shell). 


// This type of widget is used as a container fora 
// collection of widgets that dynamically resize 
// together. 


Widget frame; // Frame widget attached to Form widget. 
Widget glw; // The GL widget that we use to draw into. 
// Fallback resources for the application. 
static char * fallback_resources[] = { 
"* form* background: SGISlateBlue", // /usr/lib/rgb.txt 
"* frame* shadowType: SHADOW_IN", 
"*glwidget*width: P50"; 
"*glwidget*height: 600" , 
"*glwidget*rgba: TRUE", 
"*glwidget*doublebuffer: TRUE", 


"*glwidget*allocateBackground: TRUE", 
"*fontList: -adobe-courier-bold-r-normal--12-120-75-75-m-70-iso08859-1", 
"Mylight*geometry: 750x600+2654+370", // width, height, xoff, yoff 
"Shell2*geometry: 250x475+1020+0", 
"Shell2*background: SGISlateBlue", 
NULL 

7 

// Create the top level widget. 

toplevel = XtAppInitialize ( 


&app_context, // Application context. 
"RobotWars", // Application class. 
NULL, 0, // Command line option list. 
&arge, argv, // Command line args. 
fallback_resources, 77 

NULL , // Argument list. 

ON; // Number of arguments. 


// Create Form widget. 

// This is the top level container for below widgets. 

n = Q; 

form = XmCreateForm(toplevel, "form", wargs, n); 

// Create a Frame widget to make it so we can resize the window. 
neoau. 

XtSetArg(wargs[n], XmNbottomAttachment, XmATTACH_FORM); n++; 
XtSetArg(wargs[n], XmNleftAttachment, XmATTACH_FORM); n++; 
XtSetArg(wargs[n], XmNrightAttachment, XmATTACH_FORM); n++; 
XtSetArg(wargs[n), XmNtopAttachment, XmATTACH_FORM); n++; 
frame = XmCreateFrame (form, “frame”, wargs, n); 

// Create a GL widget. 

=r, 

XtSetArg(wargs[n], GLwNdepthSize, 1); n+t+; 

glw = GLwCreateMDrawingArea(frame, "glwidget", wargs, n); 

// ARdd callbacks to the glw widget. 
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} 


XtAddCallback(glw, GLwNginitCallback, initCB, (XtPointer) NULL); 
XtAddCallback(glw, GLwNexposeCallback, exposeCB, (XtPointer) NULL); 
XtAddCallback(glw, GLwNresizeCallback, resizeCB, (XtPointer) NULL); 
// Add in a callback for processing input keys from the keyboard. 
XtAddCallback(glw, GLwNinputCallback, inputCB, (XtPointer) NULL); 


// Add in the work procedure. 
// A work procedure is called repeatedly whenever there are no 
// events to process. 


workprocid = XtAppAddWorkProc(app_context, (XtWorkProc) drawwP, 
(XtPointer) NULL); 


// Create the control panel for the application... 
make_the_window_for_the_controls(); 

// Manage all the child widgets. 

// We delayed managing and did it in reverse order to get the right 
// size widgets automatically. 

XtManageChild(glw); 

XtManageChild (frame); 

XtManageChild(form) ; 

XtRealizeWidget(toplevel); // Instantiate it now. 
XtAppMainLoop(app_context); // Loop for events. 


// end of main(). 


———— ee eee wee ee ee ee ee we ss es ee ee ee ee ee ee ee ee es es es ee ee ee ee ee ee i 


//tuncetene in tee 
//description: This function initializes graphics modes and transformation matrices. 


static void initCB (Widget w, XtPointer, XtPointer call_data) 


{ 


// Get us a GLwDrawingAreaCallbackStruct ptr to the call_data. 


GLwDrawingAreaCallbackStruct *glptr = (GLwDrawingAreaCallbackStruct *) call_data; 
Arg wargs(1]J; // Arg temp. 

XVisualinfo *vi; // Pointer to XVisualinfo. 

GLint gdtmp; // Used in the get capability stuff below. 


// Get the visual info... 
XtSetArg(wargs[0], GLwNvisualiInfo, &vi); 
XtGetValues(w, wargs, 1); 


// Create a new GLX rendering context. 
// GL_TRUE -> Specify direct connection to graphics system (if possible). 
glx_context = glXCreateContext(XtDisplay(w), vi, 0, GL_TRUE); 


// Set the global window and display. 
global_display = XtDisplay(w)j; 
global_window = XtWindow(w) ; 


// Make this drawing area the current one. 
GLwDrawingAreaMakeCurrent(w, glx_context) ; 


// Test to see if this machine has a z-buffer. 
if((glGetIntegerv(GL_DEPTH_BITS, &gdtmp), gdtmp) == 0) 
{ 


cerr << "This machine does not have a hardware zbuffer" << endl; 
exit(0); 
} 


// Turn on z-buffering. 
glEnable(GL_DEPTH_TEST) ; 
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// Turn on Gouraud shading. 
g1lShadeModel (GL_SMOOTH) ; 


// Set the Viewport for the first draw of the window. 
glViewport (0, 0, glptr->width, glptr->height) ; 


reset_show(); 
Alselaghts oni), 


} Wy end of initcs() 


// function: exposeCB - 
// description: This routine is called whenever the window is uncovered. 


static void exposeCB(Widget w, XtPointer, XtPointer ) 


{ 
// Set the window into which GL drawing should be done. 
GLwDrawingAreaMakeCurrent(w, glx_context); 
// Draw the scene. 
draw_the_scene(); 
} 
a — — 


// function: resizeCB - 
// description: This routine is called whenever the window is moved or resized. 


static void resizeCB (Widget w, XtPointer, XtPointer call_data ) 

7 
// Get us a GlwDrawingAreaCallbackStruct ptr to the call_data. 
GLwDrawingAreaCallbackStruct *glptr = (GLwDrawingAreaCallbackStruct *) call_data; 


// Set the window into which GL drawing should be done. 
GLwDrawingAreaMakeCurrent(w, glx_context) ; 


// Set the viewport using the window size currently set. 
glViewport (0, 0, (GLsizei) glptr->width, (GLsizei) glptr->height) ; 


// Draw the scene. 
draw_the_scene(); 


// funciton: inputCB - 

// description: This routine handles all types of input from the GL widget. 
ie! In this particular example, the KeyRelease handles the 

7 Escape-Key so that its release exits the program. 


static void inputCB (Widget, XtPointer, XtPointer call_data ) 


{ 
// Get us a GLwDrawingAreaCallbackStruct ptr to the call_data. 


GLwDrawingAreaCallbackStruct *glptr = (GLwDrawingAreaCallbackStruct *) call_data; 
ehaeeascii([di); // Hold for the ascii chars returned from XLookupString. 


int nchars; // Number of characters returned from XLookupString. 
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KeySym keysym; // The X version of the returned character. 
XKeyEvent *ptr; // ptr to the Key Event structure. 
// We look at the type of event to see if we should pay attention... 


// In this example, we only pay attention to key release events. 
switch (glptr->event->type) 


{ 
case KeyRelease: 
// We must convert the keycode to a KeySym before it is possible 
// to check if it is an escape. We also dump the Ascii into the 
// array ascii. The return value from XLookupString is the 
// number of characters dumped into array ascii. 
ptr = (XKeyEvent *) gliptr->event; 
nchars = XLookupString(ptr, ascii, 1, &keysym, NULL); 
if(mchars == 1 && keysym == (KeySym) XK_Escape) 
{ 
// We have an escape. Time to exit. 
exit (0); 
} 
break; 
default: 
break; 
} // end of switch on event->type. 


} // end of inputCB. 


// function: make_the_window_for_the_controls 
// description: This function creates a second window for the control panel. 


void make_the_window_for_the_controls() 


{ 


Arg wargs[16]; // Args used with XtSetArg below. 


inter: // Used to specify number of args. 
Widget shell2; // Second shell widget for the controls. 
Widget controls; // Form widget for the toggle controls. 
Display *dpy; // The X Display... 

static @imt wero = 0; 


// Open a connection to the X server. 
apy = XtOpenDisplay(app_context, NULL, NULL, “Shelil2", NULL, 0, 
&zero, NULL); 


// Create a second applications shell. 

n = 205 

shell2 = XtAppCreateShell(NULL, “Sheli2", 
applicationShellWidgetClass, 
dpy, wargs, n); 


// Create a Form widget for the controls... 

mn, =20- 

XtSetArg(wargs[n], XmNwidth, 480); n++; 
XtSetArg(wargs[n], XmNheight, 290); n++; 

controls = XmCreateForm(shell2, “controls", wargs, n); 


// Create the Toggle widgets. 
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create_toggle_widget (controls) ; 


// Manage after creation 
XtManageChild(controls) ; 


// Realize the second shell widget. 
XtRealizeWidget (shell2) ; 


} 


// Data for the option selector. 


static char *all_option_labels[] = { “Camera 1", "Camera 2", "Camera 3", 
"Camera 4", "Camera 5", "Camera 6", 
"slow_floor”, “neutral” «fasten loous, 
De: 


static void ( *all_option_callbacks[] ) (Widget, XtPointer, XtPointer) = 
{ cameralCB, camera2CB, camera3CB, 
camera4CB, camera5CB, camera6CB, 
Slow_floorCB, neutralCB, fast_floorcB, 
Ve 


static Widget all_option_toggles[16] ; // All returned option toggle widgets. 


Static XtPointer all_translate_data[]) = { (XtPointer) &dummy, 
(XtPointer) &dummy, 
(XtPointer) &dummy, 
(XtPointer) &dummy, 
(XtPointer) &dumny, 
(XtPointer) &dummy }; 


//function: create_toggle_widget (Widget parent) 
//description: Input parent 1s expected to be a Form widget. 


la This function creates 4 different RowColumn widgets, 
He each RowColumn to hold the toggle buttons corresponding to 
la rotation, translation & scaling and reset & exit. 
[fmm rrr ere eeco--- 
void create_toggle_widget (Widget parent) 
{ 

Widget rc[4]; // We need 4 RowColumn widgets. 

Widget button; // PushButton widget. 

XmString label_string; /7 Sezing: 

Arg wargs[10]; // Same old args stuff. 

int n; // Same old args stuff. 


// Create a RowColumn widget container 

n = Q; 

rc[0] = XmCreateRowColumn (parent, “rowcol", wargs, n); 
XtManageChild(rc[0]); 


// Define a nine_entry selector for rotation. 

create_nine_entry_selector(rc[0], “option’, 
all_option_labels, 
all_option_callbacks, 
all_translate_data, 
all_option_toggles) ; 


// Create a RowColumn widget container 


n= 0; 
XtSetArg(wargs[n], XmNleftAttachment, XmATTACH_WIDGET); n++; 
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XtSetArg(wargs[n], XmNleftWidget, rc[0]); n++; 
rce[1] = XmCreateRowColumn (parent, “rowcol", wargs, n); 
XtManageChild(re[1]); 


// Create a RowColumn widget container 


no= 0; 

XtSetArg(wargs[n], XmNleftAttachment, XmATTACH_WIDGET); n++; 
XtSetArg(wargs[n], XmNleftWidget, rc[1]); n++; 

rc(2]) = XmCreateRowColumn (parent, “rowcol", wargs, n); 


XtManageChild(re[2]); 


// Create a RowColumn widget container 


m= 0; 

XtSetArg(wargs[(n], XmNleftAttachment, XmATTACH_ WIDGET); n++; 
XtSetArg(wargs[n], XmNleftWidget, rce[2]); n+t+; 

rce[3] = XmCreateRowColumn (parent, "“rowcol", wargs, n); 


XtManageChild(re[3]); 


// Now add a Reset PushButton. 

nee 

// XtSetArg(wargs[n], XmNalignment, XmALIGNMENT_CENTER); n++; 
label_string = XmStringCreateLtoR("Reset", charset); 
XtSetArg(wargs[n], XmNlabelString, label_string); n+t+; 

button = XmCreatePushButton(rc[3], "reset", wargs, n); 
XtManageChild (button) ; 

XmStringFree(label_string) ; 


// Here is a reset callback... 
XtAddCallback (button, XmNarmCallback, resetCB, (XtPointer) NULL) ; 


// Now add an Exit PushButton. 

m= 0; 

// XtSetArg(wargs[n], XmNalignment, XmALIGNMENT_CENTER) ; n++; 
label_string = XmStringCreateLtoR("Exit", charset) ; 
XtSetArg(wargs[n], XmNlabelString, label_string); n++; 

button = XmCreatePushButton(re[3], "exit", wargs, n); 
XtManageChild(button) ; 

XmStringFree (label_string) ; 


// Now add an Exit callback for the PushButton. 
XtAddCallback(button, XmNarmCallback, quitCB, (XtPointer) NULL); 


Heew0. 

// XtSetArg(wargs[n], XmNalignment, XmALIGNMENT_CENTER); n++; 
label_string = XmStringCreateLtoR("Replay", charset); 
XtSetArg(wargs[n], XmNlabelString, label string); ntt+; 
button = XmCreatePushButton(rc[3], “Replay”, wargs, n); 
XtManageChild (button) ; 

XmStringFree(label_string) ; 


// Now add a callback for the PushButton. 
XtAddCallback(button, XmNarmCallback, ReplayCB, (XtPointer) NULL) ; 


// Now add an movement PushButton. 

Nese: 

// XtSetArg(wargs[n], XmNalignment, XmMALIGNMENT_CENTER); n++; 
label_string = XmStringCreateLtoR("Pause", charset) ; 
XtSetArg(wargs[n], XmNlabelString, label_string); n++; 

button = XmCreatePushButton(rc[2], "Pause", wargs, n); 
XtManageChild (button) ; 

XmStringFree(label_string) ; 


// Now add an movement callback for the PushButton. 
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XtAddCallback(button, XmNarmCallback, movementCB, (XtPointer) NULL); 


} // end of create_toggle_widget... 


| a | ee a ee 
//function : create_nine_entry selector 
//description: This function creates a nine entry selection box for the 
// camera and the floor types. 
| a SS 
void create_nine_entry_selector ( 

Widget rc, // Parent widget is a RowColumn container. 

char *radioboxname, // Text name to use for the RadioBox. 

char *all_labels[], // All the labels for the selector. 

XtCallbackProc all_callibacks[{], // All the callbacks for each 

// opeaen. 
XtPointer all_data[], // Pointers to the data to be passed 


// to the callbacks. 


Widget togglereturns[16]) // Returned toggle button widgets. 


Widget myradio[4]; // RadloBox widgets. 

Widget separator; // Separator widget for the RadioBox. 

Arg wargs[10]; // Same old args stuff. 

dee tl; // Same old args stuff 

er eee Oil // Loop temps. 

£For(j=0; 3 < 4*eq4++) { 
n = Q; 
XtSetArg (wargs[n], XmNentryClass, xmToggleButtonWidgetClass); n++; 
myradio[j3] = XmCreateRadioBox (rc, radioboxname, wargs, n); 


XtManageChild (myradio[j]); 
if, (j.2<i))) 4 
for (i= 0 ; 1 < 6; is4) 4 
togglereturns[i] = XtCreateManagedWidget(all_labels[il, 
xmToggleButtonWidgetClass, 
myradio[j], 
NULL, 0); 
// Add a callback for this toggle button. 
XtAddCallback (togglereturns[{i], XmNarmCallback, all_callbacks[il, 
all_data[i]); 
} V7 end feone1 
n=0; 
separator = XmCreateSeparator(rc, “separator", wargs, n); 
XtManageChild(separator) ; 
} 
else i113 2-—— >) { 
Ror (1 = 6. 3 tse Oe att) of 
togglereturns[i] = XtCreateManagedWidget (all_labels[i], 
xmToggleButtonWidgetClass, 
myradio[j], 
NULIG, *0); 
// Add a callback for this toggle button. 
XtAddCallback (togglereturns[{i], XmNarmCallback, all_callbacks[il, 
all _data[i]); 
} // end for 1 
n=0; 
separator = XmCreateSeparator(rc, “separator", wargs, n); 
XtManageChild(separator) ; 
} 
} // end for j 
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// £unction: initialize _toggle_states 
// description: This function sets the toggles to their initial depressions. 


// 


void initialize_toggle_states() 


{ 


Arg wargs_false[16]; // Same old args stuff. 
Arg wargs_true[16]; // Same old args stuff. 
init i // Same old args stuff. 


// Make the argument list that says False and one that says true. 
n= 1; 

XtSetArg(wargs_false[0], XmNset, False); 

XtSetArg(wargs_true[0], XmNset, True); 


// Set all the camera toggles. 

XtSetValues (all_option_toggles[0], wargs_true, n); 
XtSetValues (all_option_toggles[1], wargs_false, n); 
XtSetValues (all_option_toggles[2], wargs_false, n); 


XtSetValues (all_option_toggles[3], wargs_false, n); 
XtSetValues(all_option_toggles[4], wargs_false, n); 
XtSetValues(all_option_toggles[(5], wargs_false, n); 
//set the floor toggles 

XtSetValues (all_option_toggles[6], wargs_false, n); 
XtSetValues (all_option_toggles[7], wargs_true, n); 
XtSetValues (all_option_toggles[8], wargs_false, n); 


Function: Gquitcs —- 
description: This function is called whenever the "Quit" menu option 
1s selected. 


static void quitCB (Widget w, XtPointer, XtPointer) 


{ 


// Bye, bye... 
XtCloseDisplay (XtDisplay (w) ); 
exit(0); 

//2 Snes or quirtcs 


eee ee ee ce ee ee ee we ee ee we we we we we wee we ee we ww we ee ee ee ee ee ee ee eee eee es es es es ee ee ee ee ee ie 


// function: resetCB - 
// description: This function is called whenever the "Reset" menu option 


ee 


Te selected: 
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static void resetCB (Widget, XtPointer, XtPointer) 


{ 


} 


reset = 1; 
reset_show(); 
// End of resetCB 
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// function: ReplaycCB - 
// description: This function is called whenever the "Replay" menu option 
el is selected. 


Static void ReplayCB (Widget, XtPointer, XtPointer) 
{ 

reset = 2; 

reset_show(); 


// function: movementCB 
// description: This function is called whenever the "pause" menu option 
if is selected. 


| eee 8 
static void movementCB (Widget w, XtPointer, XtPointer) 
{ 
if “pause ==eive { 
pause = 0; 
n = QO; 
XtSetArg(wargs[n], XmNlabelString, 
XmStringCreateLtoR("pause", XmFONTLIST_DEFAULT_TAG)); n++; 
XtSetValues(w, wargs, n); 
} 
else { 
pause = 1; 
io) = OE 
XtSetArg(wargs[n], XmNlabelString, 
XmStringCreateLtoR(" move ", XmFONTLIST_DEFAULT_TAG)); n++; 
XtSetValues(w, wargs, n); 
} 
} 
| [mmm rn nnn nn ne = =~ 
//function: drawwWP - 
//description: This function is called by the work procedure. 
a, It is called repeatedly whenever there are no events to process. 


// This function returns FALSE so that the work procedure does NOT 
la stop ecailing it. 


| [mmm nn rn ne ee = == 
GLboolean drawWwP() 
{ 
// Draw the scene again... 
draw_the_scene(); 
// If we do not return FALSE, the work procedure will stop calling 
// Ghats -EGneelon. 
return (FALSE) ; 
} 


134 


//function: draw_the_scene 
ZT This function draws the picture. 


void draw_the_scene() 
{ 
Phe wtype= 0% 
char* name = "BotAscript.dat"; 
char* name2 = "BotBscript.dat"; 
gqi@learGolonr(0:1, 0.1, 0.1, 0.0); 
glClear (GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) ; 
glMatrixMode (GL_PROJECTION) ; 
glLoadIdentity(); 
gluPerspective(45.0, 1.25, 1.0, 10000.0); 
glMatrixMode (GL_MODELVIEW) ; 
glLoadIdentity (); 


if (eyepoint == 0) { 
Guunookne (frogl, frog2, frog3, // View point. changed 100 to 500 
toadl, toad2, toad3, // Ref point, point we are looking towards. 


Cm0), 120; OnO dy 
} 


turnOnTheLightModel (); 
type = lightType; 
turnOnTheLights (type) ; 


if (slow_floor) { 

drawthefloor2(0.0, -200.0, -511.0, 1600.0);} 
else 

drawthefloor3(0.0, -200.0, -511.0, 1600.0); 


g1lMatrixMode (GL_MODELVIEW) ; 


PaintBotB(start_time, end_time, name2, pause, reset); 
PaintBotA(start_time, end_time, name, pause, reset); 


turnOffTheLights (); 
turnOffTheLightModel (); 


// Swap the buffers as we are doing double buffering. 
glXSwapBuffers (global_display, global_window) ; 


} // end of draw_the_scene 


// function: reset_show 
// The following routine sets all accumulative matrices to unit matrices. 
// This routine also resets the toggle button states. 


TY mr en reece enccea- 
void reset_show() 
{ 

slow_floor = FALSE; 

fast_floor = FALSE; 

tloorseyvie = 0; 

1f (reset == 1) { 

end_time = 0; 


cout << "Enter start time" << endl; 
cin >> start_time ; 
if (start_time < 1) { 
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staactatime = 1; 
} 
while (end_time <= start_time) { 
cout << "Enter end time" << endl; 
cin >> end_time; 
end_time --; 
} 
reset = 0; 
} 
// Set all the toggle buttons to their initial states. 
initialize _toggle_states(); 


// These next three call backs will set the floor type used in the 

// scene. Only two floor types are available but three have been set 
// up for additional functionality that can be added at a later date. 
//£unction: sew_floorCs 

//description: draws the 64 square checker floor 


static void slow_floorCB(Widget, XtPointer , XtPointer) 


slow_floor = TRUE; fast_floor = FALSE; 


//function: fast_floorcB 
//description: draws a single square floor 


| /=-==22-—-- >> === 25> - == =- =- +--+ = === -- SS > oe 
static void fast_floorCB(Widget, XtPointer, XtPointer) 

fast_floor = TRUE; slow_floor = FALSE; 

} 

9 95 SSS SSS STS SSS SS SSS eS 


//fLoneceEVON: nevtralCs 
//description: draws a single square floor, this was left for future use 
// for the 16 square floor or to add in the sensor rings. 


Static void neutralCB(Widget, XtPointer, XtPointer) 
{ 

fast_floor = TRUE; slow_floor = FALSE; 

// this will be another floor style 


// These next six call backs will set the camera angle. These angles have 
// not been set for any abitrary reason. The eyepoint was used to draw a 
// camera on the robot but has been removed at this time. Cameral is the 
// default camera and cameras 5 and 6 are at the level of the playing 

// surface. 


Static void cameralCB(Widget, XtPointer, XtPointer) 
{ 
frogs = -5ll;> freoqZ = Flocorsize; Erogl = 2000; 
toads = =—511- steoade =" 0..0- toad! = 00.0; 
eyepoint = 0; 
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static void camera2CB(Widget, XtPointer, XtPointer) 


{ 
frogl = 0.0; frog2 = FloorSize; frog3 = 2000-511; 
toadl = 0.0; toad2 = 0.0; toad3 = -511; 
eyepoint = 0; 

} 

static void camera3CB(Widget, XtPointer, XtPointer) 

{ 
frogl = -2000.0; frog2 = FloorSize; frog3 = -511; 
Poaal ="9.0- toad2 = 0.0; toad3 = -511.0; 
eyepoint = 0; 

} 

static void camera4CB(Widget, XtPointer, XtPointer) 

{ 
fheegl = 020; £rogZ = 1500.0; frog3 = -2500-511; //739 
toaay = 080; toad2 = 0.0; toad3 = 0; //-1775 
eyepoint = 0; 

? 

static void camera5CB(Widget, XtPointer, XtPointer) 

{ 
puogie=  —Eloorncize+250; £rogZ = 0.0; fmogee= -—511.0; 
toadl = FloorSize-250; toad2 = 0.0; toad3 = -511.0; 
eyepoint = 0; 

} 

static void camera6CB(Widget, XtPointer, XtPointer) 

{ 
eyepoint = 1; 

i 

[Ym nn a nn ne rn nn = = = - = -- 


77 eunet ion: Alilelights_on 
//description: turns on the lights in the scene. 


void All_lights_on() 


{ 
glEnable (GL_LIGHTO) ; 


od 


//FILENAME: materialsupport_funcs.h 

//AUTHOR: Doreen M Jones (derived from M. Zyda class notes 
//DATE: 31 MAY 1997 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY: contains function prototypes for materialsupport.c 


void turnOnTheLightModel (); 

void turnoffTheLightModel (); 

void turnOnTheLights (int type) ; 

VOid turnoOfETheLights () ; 

void turnOnMaterial(GLenum whichFace, int whichMaterial) ; 

void makeGLMaterialCalls(GLenum whichFace, 
GLfloat *ambient, 
GLfloat *diffuse, 
GLfloat *specular, 
GLfloat *shininess, 
GLfloat *emmisSive); 
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//FILENAME: materialsupport.h 
//AUTHOR: Doreen M Jones (derived from M. Zyda class notes 


//DATE: 


Sy MAY 1997 


//COMPILER: SUN/UNIX on SGI 
//SUMMARY: Defines a set of constant names for the materials. 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


oeoeccere ere ee cer oe e eee ee ew ee oe em em cm ee ee we ee ee ee te ee we we ws we ie ee = 


BRASS 1 
SHINYBRASS 2 
PEWTER 3 
SILVER 4 

GOLD 5 
SHINYGOLD 6 
PLASTER 7 
REDGLOW 8 
GREENPLASTIC 9 
BLUEPLASTIC 10 
RED 11 

WHITE | 12 

BLACK 13 


// Define a set of locations we can use... 


static int _BRASS = BRASS; 

static int _SHINYBRASS = SHINYBRASS; 

static int _PEWTER = PEWTER; 

static int SILVER = SILVER; 

static int _GOLD = GOLD; 

static int _SHINYGOLD = SHINYGOLD; 

static int _PLASTER = PLASTER; 

static int _REDGLOW = REDGLOW; 

static int _GREENPLASTIC = GREENPLASTIC; 

static int _BLUEPLASTIC = BLUEPLASTIC; 

static int _RED = RED; 

static int _WHITE = WHITE; 

static int BLACK = BLACK; 

Lf mm ree eee eee 
// end of file material support.h 

Tf mr rrr rene 


19 


//FILENAME: materialsupport.Cc 

//AUTHOR: Doreen M. Jones (derived from M. Zyda Class notes 

//DATE: 31 MAY 97 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY: These functions control the lighting and the colors used 
// in drawing the scene. 


DO a a ee ee eee ee 

#include <Xm/Xm.h> // Get the Motif stuff... 

#include <GL/GLwMDrawA.h> // We are going to use an OpenGL Motif Draw widget 
#include <GL/gl.h> // Get the OpenGL required includes. 


#include <GL/glu.h> 
#include <GL/glx.h> 


#include <iostream.h> // C++ I/O subsystem. 
#include <math.h> 
#Hinclude <stdlib.h> // Get exit() function. 


#include "mMmaterialsupport.h" // Get the names of the available materials. 
#include "materialsupport_funcs.h" // Get material support function names. 
#include "drawsupport_funcs.h" 


//£unction: turnOnTheLightModel 
//description: The following function turns on the Light Model. 


void turnOnTheLightModel () 
{ 


// A dim white for the lighting model ambient color. 
GLfloat Imodel_ambient[]) = { 0.5, 0.5, 0.5, loom 


// Set the global ambient light intensity. 
glLightModel fv (GL_LIGHT_MODEL_AMBIENT, lmodel_ambient) ; 


// Set whether the viewpoint position is local to the scene or 

// whether it should be considered to be an infinite distance away. 
// We have selected an infinite viewpoint. 

glLightModeli (GL_LIGHT_MODEL_LOCAL_VIEWER, GL_TRUE); 


// Say that we want two-sided lighting. 
glLightModeli (GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE) ; 


// Enable the lighting model (there is a glDisable()). 
glEnable (GL_LIGHTING) ; 
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//function: turnOffTheLightModel 
//description: turns off the light model 


void turnOffTheLightModel () 


i ; 
glDisable (GL_LIGHTING) ; 


//function: turnOnTheLights 

//description: creates the specific lights within the scene. Only 

/ one light has been added to the scene to speed up the program on 
// slower machines. This light was originally modified to allow for 
// spotlights. The functionality has been retained but is not used 
// in show_war.C graphics program. 


Lf mr rr 
void turnOnTheLights(int type) 
{ 
int locate; 
ee ype == 0) 
locate = 750; 
} 
else { 
locate = 350; 
} 
int place = 511; 
Glirensilatert (0, 0, -511.0); 
GuEloat LightO0-ambient(] = { O7OROHO, "0.0; 1208)- 
Gueloat lightOzeditfusell>= ~ WO, 1.091.0, 1205), 
Ghtleat lightO specular(] =" m0, 1.0% 1.0, Peer}; 
GueloatelsGht0 posi twonl(] =mtl ao, 1.0, 1.6, 70708) 
glLightfv (GL_LIGHTO, GL_AMBIENT, light0O_ambient) ; 
glLightfv(GL_LIGHT0O, GL_DIFFUSE, light0O_diffuse) ; 
glLightfv(GL_LIGHT0O, GL_SPECULAR, light0O_specular) ; 
glLightfv(GL_LIGHTO, GL_POSITION, light0O_position) ; 
// If we had a local light, we could have attenuation 
glLightf(GL_LIGHTO, GL_CONSTANT_ATTENUATION, 1.0); 
glLightf(GL_LIGHTO, GL_LINEAR_ATTENUATION, 0.0); 
glLightf(GL_LIGHT0, GL_QUADRATIC_ATTENUATION, 0.0); 
glEnable (GL_LIGHTO) ; 
glTranslatef(0, 0, place); 
} 
Vr ee 


//function: turnOnTheLights 
//description: just turns off the light after leaving the room 


void turnOffTheLights () 
{ 

glDisable(GL_LIGHTO) ; 
} 4 
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//function: turnOnMateria 
//description: this creates the colors used within the simulation and 
// includes some extra colors. The included colors are: 


ie BRASS, SHINYBRASS, PEWTER, SILVER, GOLD, SHINYGOLD, PLASTER, 
Tih REDGLOW, GREENPLASTIC, BLUEPLASTIC, RED, WHITE, BLACK 
| | =----------------- $= 7-7-7 - $= = $= === === === == === == ------------ 


void turnOnMaterial(GLenum whichFace, int whichMaterial) 


{ 


// Set the appropriate material type... 
switch (whichMaterial) 
{ 
case BRASS: 
{ 
// Here are the brass material values ... 
GLfloat brass_ambient[] = { 0.35, 0.25, 0.1, 1.0 }; 
GLfloat brass_diffuse[] = { 0.565, 1085, 0.35, 12.0 }; 
GLfloat brass_specular[] = { 0.65, 0.5, 0.35, 1.0 }; 
GLfloat brass_shininess[] = { 5.0 }; 
GLfloat emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
// Make the brass material calls. 
makeGLMaterialCalls (whichFace, 
brass_ambient, 
brass_diffuse, 
brass_specular, 
brass_shininess, 
emmissiveness) ; 
} 


break; 


case SHINYBRASS: 
{ 
// Here are the shinybrass material values 
GLfloat shinybrass_ambient[] = { 0.25, 0.15, 0.0, 1.0 
GLfloat shinybrass_diffuse[] = { 0.65, 0.5, 0.35, 1.0 
GLfloat shinybrass_specular[] = { 0.9, 0.6, 0.0, 1.0 } 
GLfloat shinybrass_shininess[] = { 10.0 }; 
GLfloat emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
// Make the shinybrass material calls. 
makeGLMaterialCalls (whichFace, 
shinybrass_ambient, 
shinybrass_diffuse, 
shinybrass_specular, 
shinybrass_shininess, 
emmissiveness) ; 
} 


break; 


case PEWTER: 
{ 
// Here are the pewter material values : 
GLfloat pewter_ambient[] = { 0.0, 0.0, 0.0, 1.0 } 
GL£Eloat pewter_diffuse[] = { 0.6, 0.55, 0.65, 1.0 }; 
GLfloat pewter_specular[] = { 0.9, 0.9, 0.95, 1.0 }; 
GLfloat pewter_shininess[] = { 10.0 }; 
GLfloat emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
// Make the pewter material calls. 
makeGLMaterialCalls (whichFace, 
pewter_ambient, 
pewter_diffuse, 
pewter_specular, 
pewter_shininess, 


142 


emmissiveness) ; 


} 


break; 


case SILVER: 
{ 
// Here are the silver material values 
GLfloat silver_ambient[] = { 0.4, 0.4, 0.4, 
GLfloat silver_diffuse[] = { 0.3, 0.3, 0.3, 
GLfloat silver_specular[] = { 0.9, 0.9, 0.95, 
GLfloat silver_shininess[] = { 30.0 }; 
GLfloat emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
// Make the silver material calls. 
makeGLMaterialCalls (whichFace, 
Silver_ambient, 
Ssilver_diffuse, 
Ssilver_specular, 
Ssilver_shininess, 
emmissiveness) ; 
} 


break; 


case GOLD: 
{ 
// Here are the gold material values 
Gliloat gold_ambient[] =a 0 .4em0 .2; ; ; 
Citloat gold diffuse[] = { 0.9, 0.5; j ; 
Ghitloat gold specular([] = { 0.7, 0.7, 0.0, 1.0 }; 
GLfloat gold_shininess[] = { 10.0 }; 
GLfloat emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
// Make the gold material calls. 
makeGLMaterialCalls (whichFace, 
gold_ambient, 
gold_diffuse, 
gold_specular, 
gold_shininess, 
emmissiveness) ; 
} 
break; 


case SHINYGOLD: 
{ 
// Here are the shinygold material values... 
GLfloat shinygold_ambient[] = { Oo4), 0.2, 0.0; 1.0 }; 
Gbeloat shinygold_diffuse[] = { 0.9, 0.5, OmOm 1-05), 
Ghitoat shinygold specular[] = { 0.9, 0.9, 0.0, 1.0 }; 
GLfloat shinygold_shininess[] = { 20.0 }; 
GLfloat emmissiveness[] = { 0.8, 0.0, 0.0, 1.0 }; 
// Make the shinygold material calls. 
makeGLMaterialCalls (whichFace, 
shinygold_ambient, 
shinygold_diffuse, 
shinygold_specular, 
shinygold_shininess, 
emmissiveness) ; 
} 


break; 


case PLASTER: 
{ 


// Here are the plaster material values 

GLfloat plaster_ambient[] = { 0.2, 0.2, 0.2, 1.0 }; 
Gltloat plaster _diffuse[] = ( 0-957m0725 70-75 1.0 }; 
Chileat plaster specular(] = { 0.0;,90.07 3070, 1.0 ); 
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} 


GLfloat plaster_shininess[] = { 1.0 }; 


GLfloat 
// Make 


emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
the plaster material calls. 


makeGLMaterialCalls (whichFace, 


break; 


case REDGLOW: 


{ 


} 


// Here 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
// Make 


plaster_ambient, 
plaster_diffuse, 
plaster_specular, 
plaster_shininess, 
emmissiveness) ; 


are the redplastic material values 
redglow_ambient[] = { 0.0, 0.0, 0.0, 
redglow_diffuse[] = { 0.0, 0.0, 0.0, 
redglow_specular[] = { 0.0, 0.0, 0.0, 0.0 
redglow_shininess[] = { 0.0 }; 


emmissiveness[] = { .0001, 0.0, 0.0, 0.0 }; 


the redplastic material calls. 


makeGLMaterialCalls (whichFace, 


break; 


redglow_ambient, 
redglow_diffuse, 
redglow_specular, 
redglow_shininess, 
emmissiveness) ; 


case CREENPLASTIC: 


{ 


} 


// Here 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
// Make 


are the greenplastic material values 
greenplastic_ambient[] (aOR ieee .3, 0. 
greenplastic_diffuse[] fm OmieeeO.5, 0. 
greenplastic_specular[] = { 0.45, 0.45, 
greenplastic_shininess[] = { 30.0 }; 
emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 
the greenplastic material calls. 


makeGLMaterialCalls (whichFace, 


break; 


greenplastic_ambient, 

greenplastic_diffuse, 

greenplastic_specular, 

greenplastic_shininess, 
emmissiveness) ; 


case BLUEPLASTIC: 


{ 


// Here 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
GLfloat 
// Make 


are the blueplastic material values 


blueplastic_ambient[] = { 0.2, 0.2, 0.2, 1 
blueplastic_difftusemim= { O05 O70, 0.0, 1. 
blueplastic speetilar[) = (70.077aE. 0, 1.0, 
blueplastic_shininess[] = { 10.0 }; 
emmissiveness[] = { 0.0, 0.0, 0.0, 0.0 }; 


the blueplastic material calls. 


makeGLMaterialCalls (whichFace, 


blueplastic_ambient, 
blueplastic_diffuse, 
blueplastic_specular, 
blueplastic_shininess, 
emmissiveness) ; 
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break; 


case RED: 
{ 

// Here are the red material va 

GLfloat red_ambient[] = { 0.2, 

GLfloat red_diffuse[] = { 1.0, 

GLfloat red_specular[] = { 1.0 

GLfloat red_shininess[] = 0 

GLfloat emmissiveness[] = 

// Make the red material calls. 

makeGLMaterialCalls (whichFace, 
red_ambient 


Mess... 


f 


red_diffuse, 
red_specular, 
red_shininess, 


emmissiveness) ; 


} 


break; 


case WHITE: 
{ 

// Here are the white material 
GLfloat white_ambient[] = { 0 
GLfloat white_diffuse[] = { l. 
GLfloat white_specular[] = { 1. 
GLfloat white_shininess[] 
GLfloat emmissiveness[] = 
// Make the red material calls. 
makeGLMaterialCalls (whichFace, 


= fated, 
fOr 0 


values... 


white_ambient, 
white_diffuse, 
white_specular, 
white_shininess, 


emmissiveness) ; 


} 


break; 


case BLACK: 
{ 


// Here are the white material 
GLfloat black_ambient [] 
GLfloat black_diffuse[] 


GLfloat black_specular[] = { 0. 


GLfloat black_shininess[] = { 
GLfloat emmissiveness[] = { 0. 


values... 


Wot 
as 
© 
a 
© 
© 


// Make the red material calls. 


makeGLMaterialCalls(whichFace, 


black_ambient, 
black_diffuse, 
black_specular, 
black_shininess, 


emmissiveness); 


} 
break; 


default: 
break; 


// end switch statement. 
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//function: turnOnMaterial 
//description: turns on the material to the color specified in the 
// function above. 


void makeGLMaterialCalls(GLenum whichFace, 
GLfloat *ambient, 
GLfloat *diffuse, 
GLfloat *specular, 
GLfloat *shininess, 
GLfloat *emmissiveness) 


// Make the material calls. 

glMaterialfv(whichFace, GL_AMBIENT, ambient) ; 
glMaterialfv(whichFace, GL_DIFFUSE, diffuse); 
glMaterialfv(whichFace, GL_SPECULAR, specular); 
glMaterialfv(whichFace, GL_SHININESS, shininess) ; 
glMaterialfv(whichFace, GL_EMISSION, emmissiveness) ; 
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//NAME: drawsSupport.h 

//AUTHOR: Doreen M. Jones (derived from M. Zyda course notes) 
//DATE: May 31, 1997 

//COMPILER: SUN/UNIX on SGI 

//SUMMARY:this file contains the function defs for drawsupport.c 
// and drawbot.c 


void drawSphere(float x, float y, float z, float radius, int nslices, int nstacks); 
void drawCube(float x, float y, float z, float sidelength) ; 
void drawCylinder(float x, float y, float z, 
float baseradius, float topradius, float height, 
int nslices, int nstacks); 
void drawDisk(float x, float y, float Zz, 
float outradius, 
int nslices, int nloops); 
void drawDisk2(float x, float y, float Zz, 
float outradius, float inradius, 
int nslices, int nloops); 
void drawPartDisk(float x, float y, float z, 
float outradius, 
float start, float stop); 
void drawthefloor(float x, float y, float z, float sidelength); 
void drawthefloor2(float x, float y, float z, float sidelength) ; 
void drawthefloor3(float x, float y, float z, float sidelength) ; 


void drawRobot (int color); 
void PaintBotA(int start, int end, char *name, int tracks, int &reset) ; 
void PaintBotB(int start, int end, char *name, int tracks, int &reset); 
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// NAME: drawsupport.c 

// AUTHOR: Doreen M. Jones (derived from M. Zyda course notes) 

// DATE: May 31, 1997 

// COMPILER: SUN/UNIX on SGI 

// SUMMARY: This file contains a series of draw routines for 

// geometric primatives: box, solid disk, open disk, partial disk, 
// cylinder, sphere, and three different floors styles. 


J fa RS a mr rr ca ee 

#include <Xm/Xm.h> // Get the Motif stuff... 

#include <GL/GLwMDrawaA.h> // We are going to use an OpenGL Motif Draw widget 
#include <GL/gl.h> // Get the OpenGL required includes. 


#include <GL/glu.h> 
#include <GL/glx.h> 


#include <iostream.h> // C++ I/O subsystem. 

#include <math.h> 

#include <stdlib.h> // Get exit() function. 

#include "“drawsupport_funcs.h" // Get the drawing function defs. 
#include "materialsupport.h" // get the colors 


#include "materialsupport_funcs.h" 


//FUNCTION: drawSphere 

//DESCRIPTION: This function draws a sphere, masking the OpenGL 
// Utility functions that are needed to draw a sphere, at the 
// specified location and size. 


void drawSphere(float x, float y, float z, float radius, int nslices, int nstacks) 


{ 


// Allocate a new Quadric object. 
GLUquadricObj *qobj = gluNewQuadric(); 


// Say we are going to fill the polygons of the sphere. 
gluQuadricDrawStyle(qobj, GLU_FILL) ; 


// Save the top of the ModelView stack. 
glMatrixMode (GL_MODELVIEW) ; 
glPushMatrix(); 


// The canonical Sphere is around the origin so move it where you want it. 
glTranslatef(x, y, 2); 


// Render the Sphere. 
gluSphere( qobj, (GLdouble) radius, nslices, nstacks) ; 


// Restore the top of the ModelView stack. 
glPopMatrix(); 


// Get rid of the space occupied by the quadric object. 
// Consider moving the creation and deletion outside or 
// consider stuffing the Sphere into a display list. 
gluDeleteQuadric (qobj) ; 
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//FUNCTION: drawCube 
//DESCRIPTION: Draw a cube with center (x,y,z), having the designated 
//sidelength. 


void drawCube(float x, float y, float z, float sidelength) 
{ 


float halfside; // length of half the side of the cube. 
float longside; 
float..o14) (3); // array to hold coords for the cube faces. 


halfside = sidelength/2.0; // Compute the halfside. 
longside = sidelength; 


// Back face. 

p[0) [0] =x-halfside; 
p[(0] [l]=y+halfside; 
p[0] [2] =z-longside; 


p{1][0]=xthalfside; 
p(1] [1] =y+halfside; 
p[{1) [2]=z-longside; 


p(2] [0] =x+halfside; 
p(2][(l])=y-halfside; 
p[(2) [2]=z-longside; 


p[(3] [0] =x-halfside; 
p[{3][1]=y-halfside; 
p[3] [2] =z-longside; 


Gitemmaist (0.0, 0.0, -1.0); 


glBegin (GL_QUADS) ; 
glVertex3fv(p[0]); 
glVertex3fv(p[1]); 
glVertex3fv(p[2]); 
glVertex3fv(p[3]); 
glEnd(); 


// draw the front face. 
p[{0] [0]=x+halfside; 
p[(0] [l]=y+thalfside; 
p[0] [2]=z+longside; 


p[1] [0]=x-halfside; 
p[1) [l]=y+halfside; 
p{1] [2]=z+longside; 


p[{2] [0] =x-halfside; 
p[(2) (l]=y-halfside; 
p[2] [(2]=z+longside; 


p[3] [0]=x+halfside; 
p[3] [1] =y-halfside; 
p[{3] [2] =z+longside; 
GiNe@emals£(0.0,70.0, 1.0); 


glBegin (GL_QUADS) ; 
glVertex3fv(p[0]); 
glVertex3fv(p[1]); 
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givertexsty(pi2 io 
glvertex3fv(p[3]); 


glEnd(); 


// Draw the top. 

p[(0] [0] =x-halfside; 
p[0) (l]=y+thalfside; 
p[(0] [2] =z-longside; 


p(1] [0] =x-halfside; 
p[{1] (1]=y+halfside; 
p[(1] [2] =z+longside; 


p(2] (0]=x+thalfside; 
p[2) (L]=ythalfside; 
p[2] [2] =z+longside; 


p[3]) [0] =x+thalfside; 
p[(3] [1] =y+thalfside; 
p[3] [2] =z-longside; 


glNormal3£(0.0, 1.0, 


glBegin(GL_QUADS) ; 


glvertex3fv(p[0)) 
glVertex3fv(p[1]) 
glVertex3fv(p[2]) 
glVertex3fv(p[3]) 


glEnd(); 


// Draw the bottom. 
p[(0) [0)=x-halfside; 
p[0)] [1] =y-halfside; 
p(0] [2]=z-longside; 


p[(1] (0]=x+halfside; 
p(1] (1l]=y-halfside; 
p[1] (2) =z-longside; 


p[{2] [0] =x+halfside; 
p(2] (1]=y-halfside; 
p[(2] {2]=z+longside; 


p(3]) [0])=x-halfside; 
p(3]) [1]=y-halfside; 
p[(3] [2] =z+longside; 


glNozmalse(g2o, -1.0, 


glBegin (GL_QUADS) ; 


glvertex3fv(p[0]) 
glVertex3fv(p[1]) 
glVertex3fv(p[2]) 
glvertex3fv(p[3]) 


glEnd(); 


OiO:); 


OO); 


// Draw the left side. 


p[0] (0) =x-halfside; 
p[(0] (1) =y-halfside; 
p[0] [2] =z-longside; 


p[(1) (0) =x-halfside; 
p[(1]) (1]=y-halfside; 
p[{1) [2] =z+longside; 
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© 12) [0] =x—=hal fside; 
p(2] [1] =y+halfside; 
p[2] [2] =z+longside; 


p[3] [0] =x-halfside; 
p[(3] [1] =y+thalfside; 
p[3) (2) =z-longside; 


Gitionmavori.|.0, 0.0, 0.0); 


glBegin (GL_QUADS) ; 
glVertex3fv(p[0]); 
glVertex3fv(p[1)); 
gliVertex3fv(p[2]); 
glVertex3fv(p[3]); 
glEnd(); 


// Draw the right side. 
p[0] [0] =x+halfside; 
p[0] (1) =y-halfside; 
p[0] [2)=z-longside; 


p[1] [0] =x+halfside; 
p[1] [1] =y+halfside; 
p[1]) [2] =z-longside; 


p[(2) (0) =x+halfside; 
p[(2] [1] =y+halfside; 
p [2] [2] =z+longside; 


p[3] [0] =x+halfside; 
p(3) (1]=y-halfside; 
p[3] [2] =z+longside; 


giNermalst£({(1.0, 0:0, 0.0); 


glBegin(GL_QUADS) ; 
glVertex3fv(p[0]); 
glVertex3fv(p[1]); 
glVertex3fv(p[2]); 
glVertex3fv(p[3]); 

glEnd(); 

// the cube is drawn. 


//FUNCTION: drawCylinder 

//DESCRIPTION: This function draws a cylinder, masking the OpenGL Utility functions 
// that are needed to draw a cylinder, at the specificed location 

// in space, with the height, and top and bottom radii designated. 


void drawCylinder(float x, float y, float z, 
float baseradius, float topradius, float height, 
int nslices, int nstacks) 


// Allocate a new Quadric object. 
GLUquadricObj *qobj = gluNewQuadric(); 


// Say we are going to fill the polygons of the cylinder. 
gluQuadricDrawStyle(qobj, GLU_FILL) ; 
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// Save the top of the ModelView stack. 
glMatrixMode (GL_MODELVIEW) ; 
glPushMatrix(); 


// The canonical Cylinder is along the z axis. 
// so shove it back half of height. 
glTranslatef(0.0, 0.0, -height/2.0); 


// Now put the center of the cylinder at x, y, Z. 

glTranslatef£(x, y, 2); 

glRotater(oUeu, 1, 0, 0); 

// Render the Cylinder. 

gluCylinder(qobj, baseradius, topradius, height, nslices, nstacks); 


// Restore the top of the ModelView stack. 
glPopMatrix(); 


// Get rid of the space occupied by the quadric object. 
// Consider moving the creation and deletion outside or 
// consider stuffing the Sphere into a display list. 
gluDeleteQuadric (qobj); 


//FUNCTION: drawPartDisk 
//DESCRIPTION: this draws a solid partial disk at the designated point 
// in space, with a a radius, outer and a start and stop angle 


void drawPartDisk(float x, float y, float z, 
float outer, 
float start, float stop) 


GLUquadricObj *gobj = gluNewQuadric(); 
gluQuadricDrawStyle (gobj, GLU_FILL); 
glMatrixMode (GL_MODELVIEW) ; 


glPushMatrix(); 

glTranslatef(x, y, 2); 

glRotatef£(90.0, 1.0, 0.0, 0.0); 

Gipocater(ts0.0, 0.0, 1.0, 0.0); 

qluPartialpisk (gobj, 0.0, outer, 10, 10, start, stop): 
glPopMatrix(); 


gluDeleteQuadric (gobj) ; 


//FUNCTION: drawDisk 
//DESCRIPTION: draws a solid disk of radius outer at the specified 
// location in space 


void drawDisk(float x, float y, float z, float outer, 
int nslices, int nloops) 

{ 

{0.02,. 0.02, 0.0, 020s 

{02,027 20 .0,-05027aee 0): 


GLfloat sgenparams[] 
GLfloat tgenparams[] 


glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR) ; 
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glTexGenfv(GL_S, GL_OBJECT_PLANE, sgenparams) ; 
glEnable (GL_TEXTURE_GEN_S) ; 


glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR) ; 
glTexGenfv(GL_S, GL_OBJECT_PLANE, tgenparams) ; 
glEnable (GL_TEXTURE_GEN_T) ; 


GLUquadricObj *gobj = gluNewQuadric() ; 
gluQuadricDrawStyle(gobj, GLU_FILL) ; 


glMatrixMode (GL_MODELVIEWw) ; 
glPushMatrix(); 
glTranslatef(x, y, 2); 
gimoeater170-0, 1.0, 090) 0.0); 
gluDisk(gobj, 0.0, outer, nslices, nloops ); 
glPopMatrix() ; 


gluDeleteQuadric(gobj); 


glDisable (GL_TEXTURE_GEN_S) ; 
glDisable (GL_TEXTURE_GEN_T) ; 


//FUNCTION: drawDisk2 

//DESCRIPTION: this draws a wire disk that can have a whole in the 
// middle and a specified amount of wires at the designated point 
// in space. 


void drawDisk2(float x, float y, float 2, 
float outer, float inner, 
intensiaces, int nloops) 


(OO 2 0 Oe 0 OO 2, 
HO=02,) O20 0202, 2070}. 


GLfloat sgenparams[] 
GLfloat tgenparams [] 


glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR) ; 
glTexGenfv(GL_S, GL_OBJECT_PLANE, sgenparams) ; 
glEnable(GL_TEXTURE_GEN_S) ; 


glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR) ; 
glTexGenfv(GL_S, GL_OBJECT_PLANE, tgenparams) ; 
glEnable(GL_TEXTURE_GEN_T) ; 


GLUquadricObj *gobj = gluNewQuadric(); 
gluQuadricDrawStyle(gobj, GLU_LINE) ; 


glMatrixMode (GL_MODELVIEW) ; 
glPushMatrix(); 

gliTranslatef(x, y, 2); 

GreotateL (90.0, 1.0, 0.0, 0.0); 

gluDisk(gobj, inner, outer, nslices, nloops ); 
glPopMatrix(); 


gluDeleteQuadric(gobj) ; 


glDisable(GL_TEXTURE_GEN_S) ; 
g1lDisable(GL_TEXTURE_GEN_T) ; 


re 


//FUNCTION: drawthefloor () 
//DESCRIPTION: this draws the square playing field floor with a large 
// checker board pattern with the sides equal to sidelength. 


void drawthefloor(float x, float y, float z, float sidelength) 
{ 


lengua: // loop temps 

float tilewidth; // width of the tiles on the floor. 
floadestx, Ez: // lowerleft coord of the floor. 
shortest lopcolor; // color flop for the checkerboard. 
float vi3l; // tmp vertex hold. 

int REDFLOP = ]; // Some constants... 

int WHITEFLOP = 2; 


// Compute the tilewidth. 
tilewidth = sidelength/8.0; 


// Compute the lowerleft coord. 
tx = x — (470*€ilewidth) > 
tz = z ~- (4.0*tilewidth); 


// Set the initial color for the color flop. 
flopcolor = RED; 


// Draw the checkerboard 
FOmiaj=0; jo< 8;  J=earh) 
{ 


// flop the color for the next time. 
1£(flopcolor == REDFLOP) 
{ 

flopcolor = WHITEFLOP; 


} 
else 
{ 
flopcolor = REDFLOP; 
} 


for(1=0; 1 < 8; 1=1+1) 


{ 


7/* tiliop the color for sthe next time */ 
Te(tlopecolor == REDFLOE) 


{ 
turnOnMaterial(GL_FRONT, BRASS); // Set the red color. 
flopcolor = WHITEFLOP; 

} 

else 

{ 
turnOnMaterial(GL_FRONT, PEWTER); // Set the white color. 
flopcolor = REDFLOP; 

} 


// Set the normal vector for the square. 
giNozmmals£(0.0, 1.0, 0.0); 


// Draw the square for the board. 
glBegin(GL_QUADS) ; 


v[O]) = tx+(i*tilewidth); // 1 
vil] = y; 
v[2]) = tz+(j*tilewidth) ; 
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glTexCoord2£(0.0, 0.0); glvVertex3fv(v) ; 


Wo = txe(i*tilewidth); // 2 
Vee: 
v({2) = tz+((j3+1)*tilewidth) ; 


glTexCoord2£(1.0, 0.0);glVertex3fv(v) ; 


v[O) = tx+((i+1)*tilewidth); // 3 
Vile = ys 
v({2) = tz+((j+1)*tilewidth) ; 


Gitexcoordzr(].0, 1.0); glVertex3fiv(v); 


v[O) = tx+((1+1)*tilewidth); // 4 
wil) = yy; 
v{2) = tz+(j*tilewidth) ; 


qimmex@oordZf£(0.0, 1.0); glVertex3fviv):; 
glEnd(); 
} // endfor i. 


} // en@ifer j. 


//FUNCTION: drawthefloor2 
//DESCRIPTION: this draws the square playing field floor with a small 
// checker board pattern with the sides equal to sidelength. 


void drawthefloor2(float x, float y, float z, float sidelength) 
it 


Pong: 1) // loop temps 


Pie Tecoumte: — 64; 

float tilewidth; // width of the tiles on the floor. 
tleat tx ,tz- // lowerleft coord of the floor. 
shore L£Elopecolor; // color flop for the checkerboard. 
PVOG Ee Vals i; // tmp vertex hold. 

int REDFLOP = 1; // Some constants... 

int WHITEFLOP = 2; 


// Compute the tilewidth. 
tilewidth = sidelength/count; 


// Compute the lowerleft coord. 
Eooe=ee— 1. > ~COuUNEeE*tilewidth) ; 
tae— a2 — (5 Count *tilewidth) ; 


/,msecteene initaal color for the color flop. 
ElopeGlor = RED; 


// Draw the checkerboard 

fomia—0- ej < count: j= ]+1) 

{ 
// flop the color for the next time. 
DaCrhepecolor == REDFLOP) 
{ 


} 


flopcolor = WHITEFLOP; 
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else 


{ 
flopcolor = REDFLOP; 


} 


for(i=0°> 1 < count; i=i+1) 


{ 
/* flop thexecelionrsfor the next tame */ 
if(flopcolor == REDFLOP) 
{! 


turnOnMaterial(GL_FRONT, PLASTER); // Set the red color. 
flopcolor = WHITEFLOP; 

} 

else 

{ 
turnOnMaterial (GL_FRONT, BRASS); // Set the white color. 
flopcolor = REDFLOP; 

} 


// Set the normal vector for the square. 
glNormal3sf£(0-0,7, 1.0, 0.0); 


// Draw the square for the board. 
glBegin(GL_QUADS) ; 


v[O0] = tx+(i*tilewidth); // 1 
Vibe = 

v[2] = tz+(j*tilewadeh); 
glVertex3fv(v); 

v({O]) = tx+(i*tilewa@th); /% 2 
v({l] = y; 

v[2] = tz+((j+1)*tilewidth) ; 


glVertex3fv(v); 


v(0O] = tx+((i+1)*tilewidth); // 3 
v{l] = y; 

v(2] = tz+((j+1)*tilewidth) ; 
glVertex3fv(v); 

vO] = tx+( (itl) *tivewiden) /7°4 
v{l] = y; 

Vila 


tz+(j*tilewidth) ; 
glVertex3fv(v); 


glEnd(); 


} [//-endicr i. 
} // Enartor 3". 


/ /FUNCTION: 
//DESCRIPTION: this draws the square playing field floor as a 
// single square with the sides equal to sidelength. 


void drawthefloor3(float x, float y, float z, float sidelength) 


{ 
float halfside = sidelength/2; 
float p[4) [3]; 
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// Draw the top. 
p[0] [0]=x-halfside; 
p[(0] (1J=y; 

p[0] [2])=z-halfside; 


p[{1][0]=x-halfside; 
p(1j (1lj=y; 
p[{1] [(2]=z+halfside; 


p[2] [0] =x+halfside; 


p[2] [lJ =y; 
p[2][(2]=z+halfside; 


p[3] [0]=x+halfside; 
p[(3] (lj=y; 
p[3] [2] =z-halfside; 


qifieormalsme(0.0, 1.0, 0.0); 


turnOnMaterial(GL_FRONT, PLASTER) ; 
turnOnMaterial (GL. BACK, PLASTER); 


glPushMatrix(); 
g1lBegin(GL_QUADS) ; 
glVertex3fv(p[0]); 
glVertex3fv(p[1]}); 
glVertex3fv(p[2]); 
glVertex3fv(p[3]); 
glEnd(); 


turnOnMaterial (GL_FRONT, GREENPLASTIC) ; 


drawSphere(-x-halfside, 


y, z-halfside, 


turnOnMaterial(GL_FRONT, BLUEPLASTIC) ; 


drawSphere(halfside, y, 
glPopMatrix(); 


z-halfside, 


20; 
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20; 


LO; 


10; TOjm 


10); 


//NAME: drawBot.C 


ee ee ee ee es ee eee ee ee es es es es es ee ee ee ee es es es ee se ee ee ee i 


//AUTHOR: Doreen M. Jones (derived from M. Zyda course notes) 


//DATE: May 31, 1997 

//COMPILER: SUN/UNIX on SGI 
//SUMMARY:This contains the 
// movement functions. The 
// could have probably been 


// provide clarity. 


#include 
#include 
#include 
#include 
#include 


#include 
#include 
#include 
#include 


#include 
#include 
#include 


<Xm/Xm.h> 
<GL/GLwMDrawA. h> 
<GL/gl.h> 
<GL/glu.h> 
<GL/glx.h> 


<iostream.h> 
<fstream.h> 
<math.h> 
<stdlib.h> 


"“drawsupport_funcs.h" 


Simbot 3D graphic and the two Simbot 
two functions to draw the Simbots 
combined into one but were not to 


// Get the Motif stuff... 
// We are going to use an OpenGL Motif Draw widget 
// Get the OpenGL required includes. 


// C++ I/O subsystem. 


// Get exit() function. 


// Get the drawing function defs. 


"materialsupport.h" 
"materialsupport_funcs.h" 


aeryte // size of the data chunks containing Simbot info 
serite 
rc 
int 


static 
static 
static 
static 


sizeA = 0; 
sizeB = 0; 
locationA; 
locationB; 


// place holders in the data files 


//function: drawRobot 

//description: puts together the 3D graphic primative to form the 

// Simbot. Due to the rotation of the forms, they are not all placed 
// exactly at the center point. 


void drawRobot (int color) 
{ 
glPushMatrix(); 
turnOnMaterial (GL_FRONT, WHITE) ; 


GrawCylinder (0.0, -150.0, -491.0, 50.0, 50.0, 40, 20, 20); 
turnOnMaterial(GL_FRONT, BLACK); 

turnOnMaterial (GL_FRONT, SILVER); 

dvawey trager(0.0, -130.0, =501:.0, 50.0, 50.0, 20,5 20,5 20); 
turnOnMaterial(GL_FRONT, RED) ; 

dmawevslanedenr(0.0, -124, =-508, 50.0, 50.0, 6, 20, 20); 
turnOnMaterial (GL_BACK, REDGLOW) ; 

turnOnMaterial (GL_BACK, PEWTER) ; 

turnOnMaterial(GL_FRONT, color); 

drawer binder (0.0, —so.0, =491.0, 50.0, °50.0,"40, 20,-20). 
turnOnMaterial(GL_BACK, color); 

GQuawoisi(0.0, —-86.0, —511..0,.50.5, 20, 20); 
turnOnMaterial(GL_BACK, PEWTER); 

turnOnMaterial(GL_FRONT, PEWTER); 

drawey lander (0.0, —50.0, —491.0, 5.0, 5-0, 40, 20, 20); 


turnOnMaterial(GL_FRONT, BLACK) ; 
turnOnMaterial (GL_BACK, BLACK); 
turnOnMaterial(GL_FRONT, PEWTER) ; 
glTranslatef(0.0, -100.0, 0.0); 
glRotatef(90.0, 0.0, 0.0, 1.0); 
turnOnMaterial(GL_FRONT, PEWTER) ; 
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dzaweylinden(0, 0, 8=461,- 5.07520; .100))20:,, 20); 
glPopMatrix(); 


//function: PaintBotA 
//description: This. function accesses the data files to obtain the 
// coordinates and rotation to which to draw the Simbot on the 


// playing field. The function will reaccess the data files where 
J// ve wlestu lett. The function will return to the start of the data 
// file or at the start times listed. 

[Of mmr ee er ec cnee 


void PaintBotA(int start, int final, char *title, int pause, int &reset) 
{ 

fieat old_ioc; 

float Itheta, robx, robz; 

int Icolor, Itime; 

char discard[256]; 


ifstream inBot(title, ios::in); 


elaelec = locationa; 
inBot.seekg(locationA) ; 


inBot >> Itime >> Itheta >> Icolor >> robx >> robz ; 
inBot.getline(discard, 250, ‘'\n’); 


if (Itime < final && pause == 0) { //get next line if not paused 
ocatrtonA = inBot.tellg(); 

} 

if (Itime == 0) { // at start determine the size of the data line 
sizeA = (locationA - old_loc); 
tee(stare '= 1 && start > 1) { 

locationA = start * sizeA; 

} 

} 

if (reset == 2) { // if replay or reset is indicated start over 
locationA = start * sizeA; 
reset = 0; 

} 


7 COucr<<, TrobotA = "; 
Vjeocut << ltaime << ° ‘ << Itheta << ’ ’ << robx <<" " << robzZ"=< send 


glPushMatrix(); 
glTranslatef(0, 0, -511.0); 
glTranslatef(robx, 0, robz); 
glRotatef(Itheta, 0.0, 1.0, 0.0); 
Gltransilate£(0, 0, 511.0); 
drawRobot (Icolor); 

glPopMatrix() ; 


TeEruri; 


5? 


//function: PaintBotA 
//description: This function accesses the data files to obtain the 
// coordinates and rotation to which to draw the Simbot on the 


// playing field. The function will reaccess the data files where 
// it last left. The function will return to the start of the data 
// file or at the start times listed. 

LY mr rr = - ---- 


void PaintBotB(int start, int final, char *title, int pause, int &reset) 


{ 


float old=itoc; 

float Itheta, robx, robz; 
int Icolor, Itime; 

char discard[256]; 


ifstream inBot(title, ios::in); 


Clamiloc =" locationgk; 
inBot.seekg(locationB) ; 


inBot >> Itime >> Itheta >> Icolor >> robx >> robz ; 
inBot.getline(discard, 560, ‘\n’'); 
if (Itime < final && pause == 0) { 
feeatcions = inBdot.tellg(); 
} 


er (Ultime "== 0) { 
sizeB = (locationB - old_loc); 
if (Start != 1 °&& start > 1) { 
locationB = start * sizeB; 
} 
} 


ee (reset a=. 2)>-{ 
locationB = start * sizeB; 
reset = QO; 


} 


/(eoue << “sopot4 = —"- 
/7eEout << Ttime << ' ' << Itheta << ' ’ << Yebx << “~” << robz <<"endal;: 


glPushMatrix(); 
glTranslatef(0, 0, -511.0); 
glTranslatef(robx, 0, robz); 
gliReotater(itheta, 0.0, 1.0,m000); 
glTranslatef(0, 0, 511.0); 
drawRobot (Icolor) ; 

glPopMatrix(); 


Frecurny, 
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APPENDIX H. VIDEO 


This video appendix contains short clips of animation illustrating the Simbots interacting 
with each other and the playing field boundaries. The first clip shows the green Simbot using 
the converted Dynamic C code against the gray Simbot using a simple track and shoot algorithm. 
The next two clips show the Simbots colliding with each other and with the playing field 


boundaries. 
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